Re: [RFC v1 0/3] driver-core: add asynch module loading support
From: Arjan van de Ven
Date: Sun Aug 31 2014 - 15:25:03 EST
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/