On Fri, Jun 02, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> A good definition of "Plug'n'Play" (PNP) is that without any
> user intervention, subsystems become usable-on-hardware-present.
I assume what you mean by subsystem is the USB core? I'll agree with you
that it is a good idea to have the USB subsystem (usbcore + HC drivers)
loaded on hardware-present to find all of the devices on the bus as well
as any insertions or removals.
However, things like SCSI will work with load-on-use since many are not
hot swap. (There are hot swap SCSI busses, right?)
That does make me think about the case where someone only uses their USB
bus to download pictures to their digital still camera every couple of
weeks. Keeping the core and HC loaded all of the time may not be
desirable.
Perhaps load all of the subsystems to find new devices. This will work
well with SCSI to find new devices (or lost devices) since the last
boot. Then unload the module and continue.
Keeping USB loaded all of the time will be necessary since it's hot
swap. Does that make sense?
> 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.
It should be able to be loaded when a device is used. Look at my
previous example of the digital camera user.
This may cause problems for the example user tho since he won't be
notified when new devices are connected if he ever uses it.
> - 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).
Agreed.
> - 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 think this ties into the previous point. usb-printer is a good case
for load-on-use since there isn't very much abiguity about it.
What can be difficult are things like the keyboard HID driver. There is
no device node associated with it that can load-on-use. Those will need
to be configured for load-on-present.
> 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.
Ahh, so you're advocating user policy on load-on-hardware-present versus
load-on-use on a per device basis?
> 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.
Something has to be configured. To correctly support load-on-use,
something needs to configure on the system that /dev/sda is associated
to usb-storage and load the driver correctly.
> > > 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.
You mean if there are no HC's on the system, usbcore automatically
unloads itself (or exits out of module_init as the case may be).
I don't see how the module could be automatically loaded to cause this
problem tho. If the user manually loads it, I guess it's their problem
then.
> > 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.
Yes, however, implementing correct dependancy information for this may be
difficult and not worth it.
It's probably a small price to pay to load all HC driver's regardless. I
just want to make sure that drivers aren't loaded for devices that don't
exist.
> > 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.
Cool, I'm gonna take a look at some stuff as well.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
