Re: [PATCH RFC] USB: Add HCD fastboot

[Simon Arlott]

On 06/08/08 21:26, Alan Stern wrote:
> On Wed, 6 Aug 2008, Simon Arlott wrote:
>
> > 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.
>
> Doing the HCD initcalls last certainly ought to work.

Right - so then all that's needed is to move usb/ before most other things that 
take a while to init, and it has some time to initialise usb devices in the 
background.

> > > "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.
>
> Whatever that involves...  /dev never truly settles; it's always 
> possible to plug in a new device or remove an old one.

Yes... I'm not sure how that part would work.

> > > 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 
>
> Please stop using the word "it" with no antecedent!  Do you mean "we"?

Yes. I'll try to avoid doing that.

> > 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.
>
> So what exactly do you recommend?

I'm not an expert on what can be done with the Makefile process, perhaps there's 
an easier way to move things around based on a config option. If host init is 
moved before device init for everyone, wouldn't there be too many side effects?

I've not tried to use usb-storage as root but presumably that works. If that 
already uses a hack of making the kernel wait X seconds before trying to mount 
root then it'll still work.

> > How many people have *all* their USB components (hcd, drivers) as modules?
>
> All the major distributions do, as far as I know.  (I haven't actually 
> checked them all to be certain.)
>
> > What do they do with their USB keyboards in the period between init and module 
> > load?
>
> Probably nothing.  What do you do on your keyboard while waiting for
> system initialization to complete?

Lack of a keyboard makes it impossible to do anything if the module fails to 
load... as I understand it when the HCD init runs, any BIOS emulation stops?
Although if HCD is a module too...

> > 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.
>
> What if usbhid is the one device driver that is compiled in?  :-)

That was the situation I was thinking of - surely that would be compiled in 
if the HCDs were?

--
Simon Arlott
--
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/