David Brownell wrote:
> USB PNP concerns are different for host controllers than for the
> devices they control. Or to put it differently, there are really
> at least three levels of PNP that I see in Linux-USB architecture:
>
> - USB itself (requires a controller), the problem I've been
> talking about here since the current stuff feels unfinished.
>
> A "load-on-hardware-present" policy is a prerequisite for the
> other layers to be able to work. We have "load-usbcore-always"
> today, which ties up resources needlessly on some hardware.
>
> - Device drivers (user or kernel mode driver support).
>
> Policy here is handled by various services including a
> system "usbd" for kernel drivers and any system services
> they require, and user oriented facilities (as in the USB
> support which the Java version of usbd uses).
>
> - Applications (gphoto, camstream, Rio hookup, Visor
> tools, ...) that use those devices through whatever API
> the drivers expose.
>
> I can see many "load-on-use" cases here as relating to which
> application a user starts, and also which user-mode driver
> that application uses.
I agree here.
The usb-core and controllers should be present as soon as the hardware is
detected (at least in the default configuration). Otherwise you loose the PnP
of the USB system itself... basically removing the only reason why you should
use the stuff (IMHO).
> Well, something is going to have to handle the specific host
> controller driver that's going to be used. And when it's all
> done, if "usbcore" doesn't see any controllers, it's wrong to
> consume _any_ of the resources an active USB subsystem needs.
Am I missing something or are you guys ignoring the fact that you cannot load
a HC driver without usb-core being present because of symbol dependancies ?
Fixable, but not something to ignore lightly, i think. We cannot do this with
the current design.
> > What would be nice is if the original device that triggered the loading
> > of modules could be factored into the dependancy decisions. Only load
> > the UHCI module since the device is on the bus with the UHCI controller.
>
> Ah ... the device wouldn't trigger any loading if the UHCI (or analagously
> OHCI) driver wasn't already loaded, and able to report the plug-in.
Not to mention that it could be on the OHCI bus by now...
> > What I'm saying is that modules were developed for a reason. Their sole
> > purpose in life is to load drivers dynamically while the system is
> > running.
>
> Which is what I was talking about. The system is running while
> it's bootstrapping, and will support all the driver loading policies
> that are necessary when it's done. In quite a few of the most
> important permutations.
maybe a multi-run boot ?
repeat the boot stage until you cannot find any new devices ?
this would allow for the most complex architectures, while not too difficult
to implement.
(maybe this can be improved by adding a little flag during each run that says:
"hey this device adds something that still need booting!". This would solve
the pcmcia/usb chicken and egg stuff.)
J.
--
________
/---------------------------------\ /--------------------\
| Johan Verrept \ / Alcatel |
| Software Development Engineer \ / De Villermontstr 38|
| xDSL Customer Premises Equipment \/ B-2550 Kontich |
| http://www.alcateldsl.com/ ALC/\TEL Belgium |
| mailto:[EMAIL PROTECTED] Phone: +32 3 450 3506 |
\-------------------------------------------------------------/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
