On Wed, 4 Dec 2002, James Bottomley wrote:
> greg@kroah.com said:
> > But doesn't the bus specific core know when drivers are attached, as
> > it was told to register or unregister a specific driver? So I don't
> > see why this is really needed.
>
> The problem is that the bus specific core registration no-longer knows if the
> probes succeeded or failed (and if they did, what devices were attached),
> since probing is controlled by the base core.
>
> What the bus needs to know is when a driver attaches to a specific device (and
> what device it has attached to).
>
> Unless you have a better way of getting the attachment information out of the
> bus after the base probes have executed, a notifier seemed to be the simplest
> thing.
I believe that the stuff you're allowing the bus to do once the driver has
been attached, is traditionally triggered by the driver in their probe()
method once they've found a valid device. Which, in most cases, is a
perfectly valid place to do it -- drivers have always been considered
masters of their own destiny, and the things that this patch allows the
bus to do seems like they should be triggered by the driver, with the bus
supplying helpers.
The fact that the probe() method is overloaded to setup the device as well
as verify that it should attach to it is a potential opportunity for
improvement. There's been talk in the past about splitting it up into
probe() and start() (or perhaps something better). The first would only
verify that the device was a valid one to attach to, and the latter would
actually do the dirty work of setting it up. It would be called in
drivers/base/bus.c::attach(), like this:
===== drivers/base/bus.c 1.26 vs edited =====
--- 1.26/drivers/base/bus.c Sun Dec 1 23:22:04 2002
+++ edited/drivers/base/bus.c Wed Dec 4 12:02:41 2002
@@ -228,6 +228,10 @@
{
pr_debug("bound device '%s' to driver '%s'\n",
dev->bus_id,dev->driver->name);
+
+ if (dev->driver->start)
+ dev->driver->start(dev);
+
list_add_tail(&dev->driver_list,&dev->driver->devices);
sysfs_create_link(&dev->driver->kobj,&dev->kobj,dev->kobj.name);
}
I don't recall why the change was never done. Perhaps because of other
distractions, or it seemed like it would be too much of a PITA to convert
drivers to a two-step init sequence (though I think it could be done in a
compatible manner).
-pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:19 EST