Re: [PATCH RFC] USB: Add HCD fastboot

[Simon Arlott <simon@fire.lp0.eu>]

On 06/08/08 20:49, Alan Stern wrote:
> On Wed, 6 Aug 2008, Simon Arlott wrote:
> 
>> > Wouldn't it be much simpler, and less objectionable, to do what I
>> > suggested earlier?  That is, add a 5-second delay at the start of
>> > hub_thread() in drivers/usb/core/hub.c.  No messing with Makefiles, no
>> > changes to the initcall scheduling.
>> 
>> Aside from 5 seconds being too long, and anything less being a race between 
>> hub_thread() and driver initcalls, it doesn't improve anything because it'll 
>> still have to wait for the devices to finish initialising in userspace instead.
> 
> Why is 5 seconds too long?  Too long for what?
> 
> What you're doing is already a race between hub_thread() and driver 
> initcalls.  My suggestion is no worse.

No, by adding a 5 second delay you're intending for the device driver initcalls 
to complete within that 5 seconds. If they take too long then the last one 
blocks everything (I realise that's ridiculous, these initcalls take <1ms when 
there are no devices yet). The best way to do is to make the driver initcalls 
before the host ones, like you suggested.

> "it'll still have to wait..."  If by "it" you mean the initcall
> thread, you're wrong.  If by "it" you mean the user, you still aren't
> necessarily correct; the user can do plenty of other things while
> waiting for USB devices to initialize.

Assuming userspace doesn't wait for all devices to settle and appear in /dev etc. 
before continuing.

> I suppose you could make the hub_thread delay time a module parameter 
> for usbcore, defaulting to 0.  Then it could be set by just the people 
> who want to use it -- many (most?) people keep their drivers in 
> modules, and it wouldn't do them any good.

It really needs to have hcd initcalls done very early so that device init 
has the rest of the (kernel and userspace) boot process to complete in the 
background. This is negated by having device drivers initialised immediately 
afterwards. Re-ordering initcalls and doing more of the init process 
asynchronously is likely to expose bugs and cause inconsistent device order 
on some systems, so if the makefile mess could be reduced then it can be a 
Kconfig option.

How many people have *all* their USB components (hcd, drivers) as modules?
What do they do with their USB keyboards in the period between init and module 
load? If even one device driver and the hcd is compiled in, they'd need to 
wait for every USB device to finish init before the usbhid probe could complete.

-- 
Simon Arlott