> > 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 was speaking in a generic sense. The first time I built a
"Plug'n'Play" system was to configure TCP/IP/NIS networks
of diskless systems (predating DHCP, which doesn't handle
the whole problem in any case).
Specifically for USB, I think that more than the core is
needed since that doesn't include either USB device drivers
or the capability to load and configure them ("usb daemon").
> 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.
Good! :-)
> 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.
As I said, the USB subsystem can be initialized by "modprobe usbcore"
(with post-installs for usbd and usbdevfs). So don't do the modprobe
until/unless you need the USB subsystem to work, and you'll get the
"hardware exists, subsystem unitialized" non-PNP case you want.
> 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?
I'm not sure I see why you'd want to find devices and then unload;
why bother? Either don't init the subsystem, or leave it running.
> > 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.
And as I said, that'd work [ assuming the kmod usage I described
is working per documentation ]. But it'd just be one configuration,
and one I would think wouldn't be typical; it seems to require
privileges that normal user applications should _never_ get.
> > - 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.
Previous "level"? Sort of. Except that usb-printer is set up to
be part of a system "printer" service with spooling etc. Perhaps
Randy's recent IEEE-1284 patch needs to get leveraged to ensure the
spooler does the right stuff; printing isn't an "application", the
hard work is all done by system services.
> 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.
Right. Again, system service -- "usbd" can drive this.
> > 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?
Actually, "administrative" policy, not "user" policy. (System
admins are users, but their particular roles mean they perform
privileged functions. "modprobe" is typically privileged, as
are network configuration operations.
That's what the current /etc/usb/policy framework supports.
Of course, if the administrative policy didn't arrange that a
driver be made available, then individual users should be able
to take a crack at things. That's how many user mode drivers
(for stuff like a Rio500 or a digital camera) will be able to
come alive.
> > 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.
Actually, /dev/sda _can_ associate with lots of things ... until it's
actually associated (perhaps usb-storage is already loaded and does it
automatically when you plug in the flash memory reader or ZIP drive),
nobody can know what _will_ be there.
I guess what I'm saying is that in that /dev/sda example, I can't
see that load-on-use could ever work; what'd be needed is a facility
to reserve names, which doesn't exist in the absence of actually
allocating them.
Or to put it differently ... /dev/sda is a physical name (the first
SCSI disk), not a logical one (first ZIP, first CF reader, etc).
> 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).
As I said, the module init has to fail cleanly.
> > 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.
Why would it be? "depmod -a" does most of the work, and the
kmod calls I described would do the rest.
> 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.
The HCDs won't load if there's no matching controller. While I
agree with you about not loading drivers, that's a policy that
reasonable folk might disagree on.
What I'd really prefer is to know that unused drivers will get
autocleaned, and that "usbd" will load the basic kernel drivers.
> > 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.
To clarify, "my laptop with test1" -- which has some really severe
OHCI failure modes that didn't exist in pre9. Basically unusable.
- Dave
> 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]
