> > This discussion wasn't about load-on-use, it was about bootstrapping
> > and load-on-hardware-present, with emphasis on USB HC hardware. If
> > you want an additional load-on-use policy, that's a different topic.
>
> That's the wrong way to think of it. People don't want
> load-on-hardware-present. They use modules for a reason, to load-on-use.
A good definition of "Plug'n'Play" (PNP) is that without any
user intervention, subsystems become usable-on-hardware-present.
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.
If someone chooses to use a USB network device whenever it's plugged in,
that's effectively "load-on-hardware-present". It's a common policy
for the current crop of (PCMIA-based) hot-pluggable network devices.
I think the USB-based ones should be able to do the same, and not require
me to switch to a system administrator role ("su" etc) and manually
enable such stuff. Ditto when the PCMCIA device being added is a USB
controller.
> > That's what the "fail cleanly" is about ... already if you modprobe
> > "usb-ohci" without an OHCI controller, it won't load, but that needs
> > also to be extended to the case of "usbcore": if there's no USB HC
> > available, it should fail cleanly, so postinstalls won't be run.
> > (Likely: usbdevfs never mounts, the usb daemon is never started.)
>
> I think you may have misunderstood me. usbcore should modprobe (or
> whatever equivalent) usb-hostcontroller. Not specific host controllers.
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.
> 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.
Note that the approach I described certainly loaded a UHCI driver
if you did something like "modprobe usb-printer" and there was a
UHCI controller, which it would never do before.
> 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.
Time to try a patch ... first, I've got to see if complete OHCI
braindeath is specific to a pre9/test1 change, or just my laptop.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
