On Tue, 8 May 2007 13:01:21 -0700 (PDT), Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Instead of changing existign probe functionality to be asynchronous, we > could *add* a new and asynchronous part to it. For example, we could make > the rule for PCI - or other bus - devices be: > > - the bus will *first* call the "probe()" function synchronously. > > - after that one has completed, we will call "probe_async()" > asynchronously at some point (it ie might be scheduled immediately > after the "probe()" call, but delayed by some arbitrary issues like > just already having too many asynchronous probes on-going or similar) Hm. This would mean that probe() would be the decision "I want to use this device", while probe_async() would be "setup my device, may take some time"? Could work. > So an unmodified driver would basically work exactly like it does now, but > if a driver is happy with being called asynchronously, it could just > change it's > > .probe = mydriver_probe > > thing into a > > .probe_async = mydriver_probe > > and we can do that ona per-driver basis with that kind of really simple > one-liner change. But probe would return int, while probe_async would return void? Two liner :) > > In fact, there is nothing wrong with having *both* a synchronous part, and > an async part: > > .probe = mydriver_setup, > .probe_async = mydriver_spin_up_and_probe_devices, > > and it would do basic setup (including, for example, the fast enumeration > of whatever devices are connected) synchronously, but then do anything > more in the async part - and the async part would still be guaranteed that > the setup has been run by the time it is scheduled (but not really have > any other guarantees). Looks like an idea. I'll sleep on it, just too tired to make sense. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
