On Tue, Apr 7, 2009 at 16:50, Chandra Seetharaman <sekharan@xxxxxxxxxx> wrote: > On Wed, 2009-04-08 at 01:22 +0200, Hannes Reinecke wrote: >> On Fri, Apr 03, 2009 at 03:43:10PM -0700, Chandra Seetharaman wrote: >> > If not, Can you accept the patches, please. >> > >> The problem here is that module autoloading doesn't work for >> device_handler. We have to have the callbacks in place _before_ >> driver probing starts as we might need to intercept the I/O >> requests and/or errors. When using modalias the module loading >> will be too late and the hooks will only be established after >> the probing has already happened. >> (The module autoloading is an asynchronous call in device_add(), >> where we don't write for it to succeed. So probing will continue >> and we woulnd't have the callbacks in place when probing >> starts). > > Your analysis is correct. > > But, the chicken-n-egg problem you described exists only for the first > device that is probed, module will be in place for the other devices. > > The first device race is handled by acting on the bus notification for > the BUS_NOTIFY_BOUND_DRIVER event (patch 3/3 in my patch list). How do you make sure, that the module is initialized when the BOUND_DRIVER event is happening? The userspace process loading the module can take any time to load, and I don't see how that is handled. Care to explain that in detail? I guess, you either need to implement a "device scan" from the module loading routine to find all currently unhandled devices, or you need to issue a blocking request_module() from inside the kernel and try to find a matching module, and then run the find again. The modalias seems not like the right solution here. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
