Re: [RFC v1 0/3] driver-core: add asynch module loading support

[Arjan van de Ven <arjan@linux.intel.com>]

>> before we added the current async approach the approach of async init calls was tried
>> At the time, Linus hated it and he was right, it was not the right thing.
>>
>> What is different this time to make this the right thing to do ?
>
> Because otherwise drivers still have to do this, but open code it. Let's say I
> have a long operations (i.e. for some touchpads it takes about 2 secs to reset
> and configure it). I can offload that part into async_schedule() so it does not
> stop initialization of the rest of the system (why would I want to delay
> initializing of USB or storage system until touchpad is ready?) but if that
> initialization fails we end up with partially bound driver and device that is
> not really operable. I would very much prefer async and sync cases be the same
> - if probe() fails the driver is not bound to the device.
>
> I think it is wrong to make async probing system-wide, but driver opt-in shoudl
> be fine and right thing to do.
>

I am completely fine if we make basically an async wrapper for
pci_register_driver() and friends.. that would be convenient I suppose.

(but then again, in reality very few drivers take real time to init... most already
do the heavy work in open(). Not all can, sure, but if you look at a bootgraph.pl
graph of a typical boot it's only a few that matter).
And many drivers need to register with a subsystem, and there's some ordering around that,
and that's why we ended up with the async cookie stuff, so that you can do the
heavy work in parallel, but order near the end at registeration-with-the-subsystem time.

But doing this on an initcall level was wrong back then, and I have yet to hear
a reason why it would be right this time.