[RFC] bind and unbind drivers from userspace through sysfs

[Greg KH]

Now that we have the internal infrastructure of the driver model
reworked so the locks aren't so global and imposing, it's possible to
bind and unbind drivers from devices from userspace with only a very
tiny ammount of code.

In reply to this email, are two patches, one that adds bind and one that
adds unbind functionality. I've added these to my trees and should show
up in the next -mm releases. Comments appreciated.

Oh, and yes, we still need a way to add new device ids to drivers from
sysfs, like PCI currently has. I'll be working on that next.

Even so, with these two patches, people should be able to do things that
they have been wanting to do for a while (like take over the what driver
to what device logic in userspace, as I know some distro installers
really want to do.)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Greg KH]

This adds a single file, "unbind", to the sysfs directory of every
device that is currently bound to a driver. To unbind the driver from
the device, write anything to this file and they will be disconnected
from each other.

Signed-off-by: Greg Kroah-Hartman <***@suse.de>

---
drivers/base/dd.c | 11 +++++++++++
1 files changed, 11 insertions(+)

--- gregkh-2.6.orig/drivers/base/dd.c 2005-06-22 17:56:48.000000000 -0700
+++ gregkh-2.6/drivers/base/dd.c 2005-06-22 17:56:59.000000000 -0700
@@ -23,6 +23,15 @@

#define to_drv(node) container_of(node, struct device_driver, kobj.entry)

+/* manually detach a device from it's associated driver. */
+/* Any write will cause it to happen. */
+static ssize_t device_unbind(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ device_release_driver(dev);
+ return count;
+}
+static DEVICE_ATTR(unbind, S_IWUSR, NULL, device_unbind);

/**
* device_bind_driver - bind a driver to one device.
@@ -46,6 +55,7 @@
sysfs_create_link(&dev->driver->kobj, &dev->kobj,
kobject_name(&dev->kobj));
sysfs_create_link(&dev->kobj, &dev->driver->kobj, "driver");
+ device_create_file(dev, &dev_attr_unbind);
}

/**
@@ -191,6 +201,7 @@
get_driver(drv);
sysfs_remove_link(&drv->kobj, kobject_name(&dev->kobj));
sysfs_remove_link(&dev->kobj, "driver");
+ device_remove_file(dev, &dev_attr_unbind);
klist_remove(&dev->knode_driver);

if (drv->remove)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Greg KH]

This adds a single file, "bind", to the sysfs directory of every driver
registered with the driver core. To bind a device to a driver, write
the bus id of the device you wish to bind to that specific driver to the
"bind" file (remember to not add a trailing \n). If that bus id matches
a device on that bus, and it does not currently have a driver bound to
it, the probe sequence will be initiated with that driver and device.

Note, this requires that the driver itself be willing and able to accept
that device (usually through a device id type table). This patch does
not make it possible to override the driver's id table.


Signed-off-by: Greg Kroah-Hartman <***@suse.de>

---
drivers/base/base.h | 1 +
drivers/base/bus.c | 36 ++++++++++++++++++++++++++++++++++++
drivers/base/dd.c | 2 +-
3 files changed, 38 insertions(+), 1 deletion(-)

--- gregkh-2.6.orig/drivers/base/bus.c 2005-06-22 23:21:11.000000000 -0700
+++ gregkh-2.6/drivers/base/bus.c 2005-06-22 23:23:19.000000000 -0700
@@ -133,6 +133,40 @@
decl_subsys(bus, &ktype_bus, NULL);


+/*
+ * Manually attach a device to a driver.
+ * Note: the driver must want to bind to the device,
+ * it is not possible to override the driver's id table.
+ */
+static int driver_bind_helper(struct device *dev, void *data)
+{
+ const char *name = data;
+
+ if ((dev->driver == NULL) &&
+ (strcmp(name, dev->bus_id) == 0))
+ return 1;
+ return 0;
+}
+
+static ssize_t driver_bind(struct device_driver *drv,
+ const char *buf, size_t count)
+{
+ struct bus_type *bus = get_bus(drv->bus);
+ struct device *dev;
+ int err = -ENODEV;
+
+ dev = bus_find_device(bus, NULL, (void *)buf, driver_bind_helper);
+ if (dev) {
+ down(&dev->sem);
+ err = driver_probe_device(drv, dev);
+ up(&dev->sem);
+ put_device(dev);
+ }
+ return err;
+}
+static DRIVER_ATTR(bind, S_IWUSR, NULL, driver_bind);
+
+
static struct device * next_device(struct klist_iter * i)
{
struct klist_node * n = klist_next(i);
@@ -396,6 +430,7 @@
module_add_driver(drv->owner, drv);

driver_add_attrs(bus, drv);
+ driver_create_file(drv, &driver_attr_bind);
}
return error;
}
@@ -413,6 +448,7 @@
void bus_remove_driver(struct device_driver * drv)
{
if (drv->bus) {
+ driver_remove_file(drv, &driver_attr_bind);
driver_remove_attrs(drv->bus, drv);
klist_remove(&drv->knode_bus);
pr_debug("bus %s: remove driver %s\n", drv->bus->name, drv->name);
--- gregkh-2.6.orig/drivers/base/base.h 2005-06-22 23:20:58.000000000 -0700
+++ gregkh-2.6/drivers/base/base.h 2005-06-22 23:21:14.000000000 -0700
@@ -5,6 +5,7 @@
extern void bus_remove_driver(struct device_driver *);

extern void driver_detach(struct device_driver * drv);
+extern int driver_probe_device(struct device_driver *, struct device *);

static inline struct class_device *to_class_dev(struct kobject *obj)
{
--- gregkh-2.6.orig/drivers/base/dd.c 2005-06-22 23:21:13.000000000 -0700
+++ gregkh-2.6/drivers/base/dd.c 2005-06-22 23:21:14.000000000 -0700
@@ -75,7 +75,7 @@
*
* This function must be called with @dev->sem held.
*/
-static int driver_probe_device(struct device_driver * drv, struct device * dev)
+int driver_probe_device(struct device_driver * drv, struct device * dev)
{
int ret = 0;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Patrick Mochel]

Post by Greg KH
This adds a single file, "unbind", to the sysfs directory of every
device that is currently bound to a driver. To unbind the driver from
the device, write anything to this file and they will be disconnected
from each other.

Do you think it would be better to put the 'unbind' file in the driver's
directory and have it accept the bus ID of a device that it's bound to?
This would make it more similar to the complementary 'bind' functionality.


Pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Greg KH]

Post by Patrick Mochel

Post by Greg KH
This adds a single file, "unbind", to the sysfs directory of every
device that is currently bound to a driver. To unbind the driver from
the device, write anything to this file and they will be disconnected
from each other.

Do you think it would be better to put the 'unbind' file in the driver's
directory and have it accept the bus ID of a device that it's bound to?
This would make it more similar to the complementary 'bind' functionality.

Yeah, you are right, I'll make that change. Heh, symmetry, what a
concept...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Dmitry Torokhov]

Post by Greg KH

Post by Patrick Mochel

Post by Greg KH
This adds a single file, "unbind", to the sysfs directory of every
device that is currently bound to a driver. To unbind the driver from
the device, write anything to this file and they will be disconnected
from each other.

Do you think it would be better to put the 'unbind' file in the driver's
directory and have it accept the bus ID of a device that it's bound to?
This would make it more similar to the complementary 'bind' functionality.

It is more complex this way. You need to do additional parsing...

Post by Greg KH
Yeah, you are right, I'll make that change. Heh, symmetry, what a
concept...

Actually, I think that both should be in device's directory. When unbinding
a device you normally don't care what driver it is bound to, you just want
to make sure that there is no driver bound to the device afterwards. I.e it
is a operation on device. When binding you could argue both ways, but then
again you usually have a piece of hardware you want to assign specific driver
for, so I'd say it is operation on device as well.

Also, some buses may implement other similar operatons, like rescan and
reconnect (serio/gameport buses). They are similar to "bind" except that
you do not specify driver at all. If bind/unbind is in the driver and
connect/reconnect are in the device's directory it will be complete mess.

[Michael Tokarev]

Dmitry Torokhov wrote:
[bind/unbind in device or driver dir in sysfs]

Post by Dmitry Torokhov
Actually, I think that both should be in device's directory. When unbinding
a device you normally don't care what driver it is bound to, you just want
to make sure that there is no driver bound to the device afterwards. I.e it
is a operation on device. When binding you could argue both ways, but then
again you usually have a piece of hardware you want to assign specific driver
for, so I'd say it is operation on device as well.

A small comment. How about having one file named 'bind', which acts like
either bind or unbind if nothing (empty string) has written to it?

(for fun.. that'd be 'driver' file, which, when read, returns the name
of the driver currently bound to the device.. but too bad, 'driver' is
a symlink already...)

/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Bill Nottingham]

Post by Greg KH
Even so, with these two patches, people should be able to do things that
they have been wanting to do for a while (like take over the what driver
to what device logic in userspace, as I know some distro installers
really want to do.)

Playing devils advocate, with this, the process flow is:

- kernel sees a new device
- kernel sends hotplug event for bus with slot, address, vendor id, etc.
- userspace loads a module based on that info
<some sort of synchronization here waiting for driver to initialize>
- userspace echos to sysfs to bind device
- kernel sends hotplug device event
- userspace creates device node, then continues with device

This looks:
a) inefficient
b) an awful lot like the PCMCIA model. Which... eww.

Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Greg KH]

Post by Bill Nottingham

Post by Greg KH
Even so, with these two patches, people should be able to do things that
they have been wanting to do for a while (like take over the what driver
to what device logic in userspace, as I know some distro installers
really want to do.)

- kernel sees a new device
- kernel sends hotplug event for bus with slot, address, vendor id, etc.
- userspace loads a module based on that info
<some sort of synchronization here waiting for driver to initialize>
- userspace echos to sysfs to bind device
- kernel sends hotplug device event
- userspace creates device node, then continues with device

Yeah, I'm not saying I think it's a good process flow for people to
implement. But if they want to, they now can.

The main reason for this is for drivers that replace built in drivers,
or multiple modules for the same device (think of new rev of driver,
both loaded at once, some devices should bind to the new one, other
devices you want staying with the old one due to it controlling your
root partition.) Now userspace has a chance to unbind and bind devices
to drivers in those situations, which it never could before.

But remember, I'm not changing the way things bind to devices here, like
requiring userspace to pick the driver for the device, so no one lives
will change at all, if they don't want to.

Hope this helps explain it.

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Dmitry Torokhov]

Post by Greg KH
Now that we have the internal infrastructure of the driver model
reworked so the locks aren't so global and imposing, it's possible to
bind and unbind drivers from devices from userspace with only a very
tiny ammount of code.
In reply to this email, are two patches, one that adds bind and one that
adds unbind functionality. I've added these to my trees and should show
up in the next -mm releases. Comments appreciated.
Oh, and yes, we still need a way to add new device ids to drivers from
sysfs, like PCI currently has. I'll be working on that next.

I think this is an overkill if you can do manual bind/unbind.

Post by Greg KH
Even so, with these two patches, people should be able to do things that
they have been wanting to do for a while (like take over the what driver
to what device logic in userspace, as I know some distro installers
really want to do.)

I think bind/unbind should be bus's methods and attributes should be
created only if bus supports such operations. Some buses either have
or may need additional locking considerations and will not particularly
like driver core getting in the middle of things.

Btw, do we really need separate attributes for bind/unbind?

[Greg KH]

Post by Dmitry Torokhov

Post by Greg KH
Now that we have the internal infrastructure of the driver model
reworked so the locks aren't so global and imposing, it's possible to
bind and unbind drivers from devices from userspace with only a very
tiny ammount of code.
In reply to this email, are two patches, one that adds bind and one that
adds unbind functionality. I've added these to my trees and should show
up in the next -mm releases. Comments appreciated.
Oh, and yes, we still need a way to add new device ids to drivers from
sysfs, like PCI currently has. I'll be working on that next.

I think this is an overkill if you can do manual bind/unbind.

No, this is needed. You can only bind a device to a driver that will
accept it. As we can not add new device ids to all drivers yet (only
PCI supports that), this isn't as useful as it could be. I'll be moving
that PCI code into the driver core, so that all busses that want to
support this (adding new device ids on the fly), can.

Post by Dmitry Torokhov

Post by Greg KH
Even so, with these two patches, people should be able to do things that
they have been wanting to do for a while (like take over the what driver
to what device logic in userspace, as I know some distro installers
really want to do.)

I think bind/unbind should be bus's methods and attributes should be
created only if bus supports such operations. Some buses either have
or may need additional locking considerations and will not particularly
like driver core getting in the middle of things.

Examples of such? Yes, a bus that isn't really expecting this to
happen, as it has some odd locking logic in the
registering/unregistering of a new driver for it, might have issues.
But I'd say that this is the bus's fault, not the driver core's fault.

Becides, you can just have the bus fail such a bind/unbind attempt, if
you really want to do that.

Anyway, I've tested this with PCI and USB devices, and they both work
just fine, and those are the busses that the majority of people want
this functionality for.

Post by Dmitry Torokhov
Btw, do we really need separate attributes for bind/unbind?

Overloading a single file would be messier. The overhead for an
additional attribute per driver is quite small (I move the unbind
attribute to the driver, as it makes more sense there as Pat mentioned.)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Dmitry Torokhov]

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH
Now that we have the internal infrastructure of the driver model
reworked so the locks aren't so global and imposing, it's possible to
bind and unbind drivers from devices from userspace with only a very
tiny ammount of code.
In reply to this email, are two patches, one that adds bind and one that
adds unbind functionality. I've added these to my trees and should show
up in the next -mm releases. Comments appreciated.
Oh, and yes, we still need a way to add new device ids to drivers from
sysfs, like PCI currently has. I'll be working on that next.

I think this is an overkill if you can do manual bind/unbind.

No, this is needed. You can only bind a device to a driver that will
accept it. As we can not add new device ids to all drivers yet (only
PCI supports that), this isn't as useful as it could be. I'll be moving
that PCI code into the driver core, so that all busses that want to
support this (adding new device ids on the fly), can.

Yes, you are right, sorry.

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH
Even so, with these two patches, people should be able to do things that
they have been wanting to do for a while (like take over the what driver
to what device logic in userspace, as I know some distro installers
really want to do.)

I think bind/unbind should be bus's methods and attributes should be
created only if bus supports such operations. Some buses either have
or may need additional locking considerations and will not particularly
like driver core getting in the middle of things.

Examples of such?

serio, gameport. Everything is protected by a semaphore, partly for
historical reasons, partly because when adding children devices parent
devices need to be locked too...

Post by Greg KH
Yes, a bus that isn't really expecting this to
happen, as it has some odd locking logic in the
registering/unregistering of a new driver for it, might have issues.
But I'd say that this is the bus's fault, not the driver core's fault.

I don't think so. Up to now all driver core iteractions were under
individual bus code control. Now out of sudden you allow disconnecting
device from its driver from outside of bus control and you are saying
that's all right. Driver core is a framework; buses use driver core to
simplify their tasks but driver core does not really control their
operations.

Post by Greg KH
Becides, you can just have the bus fail such a bind/unbind attempt, if
you really want to do that.

How can you do it cleanly? probe and remove routined do not have any idea
how they were called.

Post by Greg KH
Anyway, I've tested this with PCI and USB devices, and they both work
just fine, and those are the busses that the majority of people want
this functionality for.

That is really sloppy. "It happens to work for 2 buses I care about so it
must be perfect"?

Post by Greg KH

Post by Dmitry Torokhov
Btw, do we really need separate attributes for bind/unbind?

Overloading a single file would be messier. The overhead for an
additional attribute per driver is quite small (I move the unbind
attribute to the driver, as it makes more sense there as Pat mentioned.)

Let me ask again - what if we need more operations similar to [un]bind,
such as rescan? They do not use a specific driver but work for device.
If you keep bind/unbind in driver and rescan/reconnect/etc in device
subdirectoty it will be rather messy. Please consider movin in the
opposite directtion - have bind and unbind attributes of device, not
driver.

Also, what about rolling bind_mode attribute into driver core as well?

[Greg KH]

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH
Even so, with these two patches, people should be able to do things that
they have been wanting to do for a while (like take over the what driver
to what device logic in userspace, as I know some distro installers
really want to do.)

I think bind/unbind should be bus's methods and attributes should be
created only if bus supports such operations. Some buses either have
or may need additional locking considerations and will not particularly
like driver core getting in the middle of things.

Examples of such?

serio, gameport. Everything is protected by a semaphore, partly for
historical reasons, partly because when adding children devices parent
devices need to be locked too...

Why do parent devices need to be locked? Reference counting in the
driver core should take care of everything properly, right? Also, these
are not hotpluggable devices, so it should be a lot easier :)

Post by Dmitry Torokhov

Post by Greg KH
Yes, a bus that isn't really expecting this to
happen, as it has some odd locking logic in the
registering/unregistering of a new driver for it, might have issues.
But I'd say that this is the bus's fault, not the driver core's fault.

I don't think so. Up to now all driver core iteractions were under
individual bus code control. Now out of sudden you allow disconnecting
device from its driver from outside of bus control and you are saying
that's all right. Driver core is a framework; buses use driver core to
simplify their tasks but driver core does not really control their
operations.

Well, yes and no. I see the driver core driving a lot of interactions,
due to the probing and matching and disconnecting all coming from the
core, but I guess as they are usually initiated from the bus itself, I
can see how you feel this way also. So ok, yes, this is a change, I
agree. But it isn't one that should cause major issues.

Post by Dmitry Torokhov

Post by Greg KH
Becides, you can just have the bus fail such a bind/unbind attempt, if
you really want to do that.

How can you do it cleanly? probe and remove routined do not have any idea
how they were called.

You can set a flag if those functions come from your own bus (due to
device/driver add/remove) and check that, but I agree, that's an ugly
hack...

Post by Dmitry Torokhov

Post by Greg KH
Anyway, I've tested this with PCI and USB devices, and they both work
just fine, and those are the busses that the majority of people want
this functionality for.

That is really sloppy. "It happens to work for 2 buses I care about so it
must be perfect"?

Heh, at least I tried 2 :)

No, I don't mean to be sloppy, I just tested what I had availble, like
almost everyone else.

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov
Btw, do we really need separate attributes for bind/unbind?

Overloading a single file would be messier. The overhead for an
additional attribute per driver is quite small (I move the unbind
attribute to the driver, as it makes more sense there as Pat mentioned.)

Let me ask again - what if we need more operations similar to [un]bind,
such as rescan?

"rescan"? Like reprobe the bus address space? That sounds like a bus
specific issue. But if you like I could add a general bus callback for
that and an attribute for it. I know pci could use that for some odd
cases (see the fakephp driver for an example of how to do rescan for pci
devices from a driver itself.)

Post by Dmitry Torokhov
They do not use a specific driver but work for device.

Yes, and as such, rescan should be a bus attribute, not a driver or
device one.

Post by Dmitry Torokhov
If you keep bind/unbind in driver and rescan/reconnect/etc in device
subdirectoty it will be rather messy. Please consider movin in the
opposite directtion - have bind and unbind attributes of device, not
driver.

No, I put bind/unbind in the driver directory. There is no additions to
the device directory.

Post by Dmitry Torokhov
Also, what about rolling bind_mode attribute into driver core as well?

Um, I don't recall what you are referring to here. Have a
pointer/patch?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Dmitry Torokhov]

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH
Even so, with these two patches, people should be able to do things that
they have been wanting to do for a while (like take over the what driver
to what device logic in userspace, as I know some distro installers
really want to do.)

I think bind/unbind should be bus's methods and attributes should be
created only if bus supports such operations. Some buses either have
or may need additional locking considerations and will not particularly
like driver core getting in the middle of things.

Examples of such?

serio, gameport. Everything is protected by a semaphore, partly for
historical reasons, partly because when adding children devices parent
devices need to be locked too...

Why do parent devices need to be locked? Reference counting in the
driver core should take care of everything properly, right? Also, these

Children devices access hardware thtough their parent, which has to be
functional at that time, otherwise if you initializing child device
while parent is half gone you'll get bunch of errors reported. And
again - historical reasons - when driver core did not allow adding
children from parents probe routines serio core had to work around it
and it required additional locking.

Post by Greg KH
are not hotpluggable devices, so it should be a lot easier :)

Some of them are and some are not. Hot-plugging an PS/2 mouse or
keyboard usually works, although there are exceptions.

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH
Yes, a bus that isn't really expecting this to
happen, as it has some odd locking logic in the
registering/unregistering of a new driver for it, might have issues.
But I'd say that this is the bus's fault, not the driver core's fault.

I don't think so. Up to now all driver core iteractions were under
individual bus code control. Now out of sudden you allow disconnecting
device from its driver from outside of bus control and you are saying
that's all right. Driver core is a framework; buses use driver core to
simplify their tasks but driver core does not really control their
operations.

Well, yes and no. I see the driver core driving a lot of interactions,
due to the probing and matching and disconnecting all coming from the
core, but I guess as they are usually initiated from the bus itself, I
can see how you feel this way also. So ok, yes, this is a change, I
agree. But it isn't one that should cause major issues.

It is fixable and I meant to cange it, but not ATM and I hate leaving
the code with bad locking in kernel proper ;(

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov
Btw, do we really need separate attributes for bind/unbind?

Overloading a single file would be messier. The overhead for an
additional attribute per driver is quite small (I move the unbind
attribute to the driver, as it makes more sense there as Pat mentioned.)

Let me ask again - what if we need more operations similar to [un]bind,
such as rescan?

"rescan"? Like reprobe the bus address space? That sounds like a bus
specific issue. But if you like I could add a general bus callback for
that and an attribute for it. I know pci could use that for some odd
cases (see the fakephp driver for an example of how to do rescan for pci
devices from a driver itself.)

No, it for entire bus space. Imagine you have a device that is marked
as "bind_mode=manual" because normally you don't want to have it
activated for some reason. Later you want to activate it. Right now in
serio you can do:

echo -n "rescan" > /sys/bus/serio/devices/serioX/drvctl

and it will do the standard binding (match + probe) for that device
only. It is different from bus-wide rescan operation. Maybe rescan is
not the best name, but that what I have in serio for now.

Reconnect is indeed bus-specific issue but it is very close to rescan.
We already know the driver, we just want to reinitialize hardware, if
possible. Helps to keep input devices the same when mouse goes crazy
for some reason.

Post by Greg KH

Post by Dmitry Torokhov
They do not use a specific driver but work for device.

Yes, and as such, rescan should be a bus attribute, not a driver or
device one.

See above, I want a per-device operation here. Bus-wide one could be
also useful, but I was talking about per-device.

Post by Greg KH

Post by Dmitry Torokhov
If you keep bind/unbind in driver and rescan/reconnect/etc in device
subdirectoty it will be rather messy. Please consider movin in the
opposite directtion - have bind and unbind attributes of device, not
driver.

No, I put bind/unbind in the driver directory. There is no additions to
the device directory.

Could you give your rationale for putting it in driver?

Post by Greg KH

Post by Dmitry Torokhov
Also, what about rolling bind_mode attribute into driver core as well?

Um, I don't recall what you are referring to here. Have a
pointer/patch?

No patch at the moment, there were quite few changes since I sent it
to you last time. You could take a look in serio for the usage though.
Basically both drivers and devices get a new attribute "bind_mode"
(auto|manual). When bind mode is set to manual devices are bound to
driver only when user explicitely says so. This allows having 2+
drivers for the same hardware at the same time. The preferred one has
bind_mode=auto, secondary has bind_mode=manual. Take for example
serio_raw. We really want psmouse be loaded by default but if user
needs raw access to a specific serio port he can manually bind
serio_raw module to that port.

[Greg KH]

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH
Even so, with these two patches, people should be able to do things that
they have been wanting to do for a while (like take over the what driver
to what device logic in userspace, as I know some distro installers
really want to do.)

I think bind/unbind should be bus's methods and attributes should be
created only if bus supports such operations. Some buses either have
or may need additional locking considerations and will not particularly
like driver core getting in the middle of things.

Examples of such?

serio, gameport. Everything is protected by a semaphore, partly for
historical reasons, partly because when adding children devices parent
devices need to be locked too...

Why do parent devices need to be locked? Reference counting in the
driver core should take care of everything properly, right? Also, these

Children devices access hardware thtough their parent, which has to be
functional at that time, otherwise if you initializing child device
while parent is half gone you'll get bunch of errors reported. And
again - historical reasons - when driver core did not allow adding
children from parents probe routines serio core had to work around it
and it required additional locking.

Ok, that locking can now be removed :)

Post by Dmitry Torokhov

Post by Greg KH
are not hotpluggable devices, so it should be a lot easier :)

Some of them are and some are not. Hot-plugging an PS/2 mouse or
keyboard usually works, although there are exceptions.

hot-plugging a ps/2 device is a short trip to a burnt out motherboard.
I've worked with the ps/2 specs long enough to know that :)

Anyway, you aren't discovering them on the fly, but I see how a rescan
would help you out here, right?

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov
Btw, do we really need separate attributes for bind/unbind?

Overloading a single file would be messier. The overhead for an
additional attribute per driver is quite small (I move the unbind
attribute to the driver, as it makes more sense there as Pat mentioned.)

Let me ask again - what if we need more operations similar to [un]bind,
such as rescan?

"rescan"? Like reprobe the bus address space? That sounds like a bus
specific issue. But if you like I could add a general bus callback for
that and an attribute for it. I know pci could use that for some odd
cases (see the fakephp driver for an example of how to do rescan for pci
devices from a driver itself.)

No, it for entire bus space. Imagine you have a device that is marked
as "bind_mode=manual" because normally you don't want to have it
activated for some reason.

I don't like "modes" like that. Just have the driver have no built in
ids, then use the addition of a dynamic id from userspace do the bind,
like pci.

Post by Dmitry Torokhov
echo -n "rescan" > /sys/bus/serio/devices/serioX/drvctl
and it will do the standard binding (match + probe) for that device
only. It is different from bus-wide rescan operation. Maybe rescan is
not the best name, but that what I have in serio for now.

Sure, for this I think it should be a bus specific thing.

Post by Dmitry Torokhov
Reconnect is indeed bus-specific issue but it is very close to rescan.
We already know the driver, we just want to reinitialize hardware, if
possible. Helps to keep input devices the same when mouse goes crazy
for some reason.

But rescan/reconnect is a bus thing. The driver core never kicks this
off, nor should it.

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov
They do not use a specific driver but work for device.

Yes, and as such, rescan should be a bus attribute, not a driver or
device one.

See above, I want a per-device operation here. Bus-wide one could be
also useful, but I was talking about per-device.

per-device scan doesn't make much sense for other busses, does it?

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov
If you keep bind/unbind in driver and rescan/reconnect/etc in device
subdirectoty it will be rather messy. Please consider movin in the
opposite directtion - have bind and unbind attributes of device, not
driver.

No, I put bind/unbind in the driver directory. There is no additions to
the device directory.

Could you give your rationale for putting it in driver?

The driver is the thing you want to have bound to a device. Putting it
in every device directory would make the 20K scsi device people very
unhappy as I take up even more of their 31bit memory :)

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov
Also, what about rolling bind_mode attribute into driver core as well?

Um, I don't recall what you are referring to here. Have a
pointer/patch?

No patch at the moment, there were quite few changes since I sent it
to you last time. You could take a look in serio for the usage though.
Basically both drivers and devices get a new attribute "bind_mode"
(auto|manual). When bind mode is set to manual devices are bound to
driver only when user explicitely says so. This allows having 2+
drivers for the same hardware at the same time. The preferred one has
bind_mode=auto, secondary has bind_mode=manual. Take for example
serio_raw. We really want psmouse be loaded by default but if user
needs raw access to a specific serio port he can manually bind
serio_raw module to that port.

Ah, ok, now I remember. I still think this is more complex than needed,
but don't have an alternative proposal right now :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Dmitry Torokhov]

Post by Greg KH

Post by Dmitry Torokhov
Children devices access hardware thtough their parent, which has to be
functional at that time, otherwise if you initializing child device
while parent is half gone you'll get bunch of errors reported. And
again - historical reasons - when driver core did not allow adding
children from parents probe routines serio core had to work around it
and it required additional locking.

Ok, that locking can now be removed :)

Yes and it is great. I just need some time to do it.

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH
are not hotpluggable devices, so it should be a lot easier :)

Some of them are and some are not. Hot-plugging an PS/2 mouse or
keyboard usually works, although there are exceptions.

hot-plugging a ps/2 device is a short trip to a burnt out motherboard.
I've worked with the ps/2 specs long enough to know that :)

I am afraid this is somewhat old data. As far as I know modern PS/2 ports
allow hot-plugging just fine. Especially notebooks. Ask Vojtech.

Post by Greg KH
Anyway, you aren't discovering them on the fly, but I see how a rescan
would help you out here, right?

It really depends. Normally, when a new PS/2 device is plugged we get
something in the port and this will internally (bus) schedule rescan,
which will detect the kindof device plugged and will load proper driver.

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov
Btw, do we really need separate attributes for bind/unbind?

Overloading a single file would be messier. The overhead for an
additional attribute per driver is quite small (I move the unbind
attribute to the driver, as it makes more sense there as Pat mentioned.)

Let me ask again - what if we need more operations similar to [un]bind,
such as rescan?

"rescan"? Like reprobe the bus address space? That sounds like a bus
specific issue. But if you like I could add a general bus callback for
that and an attribute for it. I know pci could use that for some odd
cases (see the fakephp driver for an example of how to do rescan for pci
devices from a driver itself.)

No, it for entire bus space. Imagine you have a device that is marked
as "bind_mode=manual" because normally you don't want to have it
activated for some reason.

I don't like "modes" like that. Just have the driver have no built in
ids, then use the addition of a dynamic id from userspace do the bind,
like pci.

This is a bit different. One can say that adding new device ID is similar
to overclocking - it may work but all bets are off. In bind mode case
driver explicitely specifies set of devices it supposed to support, the
only difference is that it is considered "secondary" and will require
user intervention to bind. But the driver's author "certified" that the
driver should work with given hardware.

Post by Greg KH

Post by Dmitry Torokhov
echo -n "rescan" > /sys/bus/serio/devices/serioX/drvctl
and it will do the standard binding (match + probe) for that device
only. It is different from bus-wide rescan operation. Maybe rescan is
not the best name, but that what I have in serio for now.

Sure, for this I think it should be a bus specific thing.

Post by Dmitry Torokhov
Reconnect is indeed bus-specific issue but it is very close to rescan.
We already know the driver, we just want to reinitialize hardware, if
possible. Helps to keep input devices the same when mouse goes crazy
for some reason.

But rescan/reconnect is a bus thing. The driver core never kicks this
off, nor should it.

Driver core never kicks off anything. Everything either originates from
a bus or userspace. Bind/unbind is not initiated by driver core itself
either - you have a user requesting it (or driver/device become available
during bus initialization). The same with rescan (when initiated by user).

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov
They do not use a specific driver but work for device.

Yes, and as such, rescan should be a bus attribute, not a driver or
device one.

See above, I want a per-device operation here. Bus-wide one could be
also useful, but I was talking about per-device.

per-device scan doesn't make much sense for other busses, does it?

I am not sure. I guess if you also have bind_mode it might and it looks
like not only I want something like bind_mode.

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov
If you keep bind/unbind in driver and rescan/reconnect/etc in device
subdirectoty it will be rather messy. Please consider movin in the
opposite directtion - have bind and unbind attributes of device, not
driver.

No, I put bind/unbind in the driver directory. There is no additions to
the device directory.

Could you give your rationale for putting it in driver?

The driver is the thing you want to have bound to a device.

You can argue it both ways (I like the view whan device is an object you
perform some operation on and therefore action attributes are better suited
in devices directtory).

Post by Greg KH
Putting it
in every device directory would make the 20K scsi device people very
unhappy as I take up even more of their 31bit memory :)

I see. That would be an argument for folding all such operationsinto one
attribute with bus-specific multiplexor. But really, 20K scsi people are
probably better off without sysfs (they should still have hotplug events
as far as I can see so hotplug/usev should still work).

Just to reiterate - by beef is that if you put [un]bind into separate
directory similar operations will be split across 2 subdirectories.

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH

Post by Dmitry Torokhov
Also, what about rolling bind_mode attribute into driver core as well?

Um, I don't recall what you are referring to here. Have a
pointer/patch?

No patch at the moment, there were quite few changes since I sent it
to you last time. You could take a look in serio for the usage though.
Basically both drivers and devices get a new attribute "bind_mode"
(auto|manual). When bind mode is set to manual devices are bound to
driver only when user explicitely says so. This allows having 2+
drivers for the same hardware at the same time. The preferred one has
bind_mode=auto, secondary has bind_mode=manual. Take for example
serio_raw. We really want psmouse be loaded by default but if user
needs raw access to a specific serio port he can manually bind
serio_raw module to that port.

Ah, ok, now I remember. I still think this is more complex than needed,
but don't have an alternative proposal right now :)

I think it is simplier and safer than adding a new device ID to a driver.
Plus, one might not want to bind that driver to all available devices -
imagine I have a MUX controller (4 AUX ports) and I have standard PS/2
mouse bound to serio1 and a special device I want to have raw access to
on seio4. All 4 serio ports have the same ID, so if I simply add this ID
to serio_raw it has a chance to bind to all 4 ports. With bind mode I
don't need to worry that it will "steal" port it I did not want it to
touch.

[Greg KH]

Post by Dmitry Torokhov

Post by Greg KH
Putting it
in every device directory would make the 20K scsi device people very
unhappy as I take up even more of their 31bit memory :)

I see. That would be an argument for folding all such operationsinto one
attribute with bus-specific multiplexor. But really, 20K scsi people are
probably better off without sysfs (they should still have hotplug events
as far as I can see so hotplug/usev should still work).

The 20k scsi people need sysfs. They did the backing store patches for
it, to make it work sane on their boxes. They need persistant device
naming more than almost anyone else. udev previously would not work
without sysfs. For 2.6.12, it now almost can (haven't tried for sure,
but I think we are now there.)

Post by Dmitry Torokhov
Just to reiterate - by beef is that if you put [un]bind into separate
directory similar operations will be split across 2 subdirectories.

But I didn't. They are now both in the same directory. Look at Linus's
tree :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Dmitry Torokhov]

Post by Greg KH

Post by Dmitry Torokhov

Post by Greg KH
Putting it
in every device directory would make the 20K scsi device people very
unhappy as I take up even more of their 31bit memory :)

I see. That would be an argument for folding all such operationsinto one
attribute with bus-specific multiplexor. But really, 20K scsi people are
probably better off without sysfs (they should still have hotplug events
as far as I can see so hotplug/usev should still work).

The 20k scsi people need sysfs. They did the backing store patches for
it, to make it work sane on their boxes. They need persistant device
naming more than almost anyone else. udev previously would not work
without sysfs. For 2.6.12, it now almost can (haven't tried for sure,
but I think we are now there.)

I believe you can make it work ;)

Post by Greg KH

Post by Dmitry Torokhov
Just to reiterate - by beef is that if you put [un]bind into separate
directory similar operations will be split across 2 subdirectories.

But I didn't. They are now both in the same directory. Look at Linus's
tree :)

You misunderstood me. I know that both bind and unbind are in the same
directory. I am talking about reconnect/rescan being in one directory
while bind/unbind are in the other while they all perform related
operations.