On Fri, Jun 02, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> > 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.
Where does your PCI probing come into effect? I'm just a bit confused on
that point.
usbcore will use PCI probing? "usbd" will use PCI probing?
> > 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.
Because Unix, and more importantly Linux, is dumb with respect to
dynamic hardware configurations.
Since people like Linus are uninterested in a sane solution supporting
dynamic device insertion and removal some other kludge must be developed.
> > > - 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.
I think of application as something outside of the kernel, but I guess
your description is a bit more accurate. We're thinking the same thing
tho which is the important part.
> > > 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.
"user" meaning something outside of the kernel. Like before, we're
thinking the same thing.
> > 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.
Exactly. This is all apart of the whole mess with dynamic device
insertion and removal with Linux.
We're already running into this problem now. Opening /dev/sda can load a
specific SCSI host adapter driver, and /dev/sdb can open another.
There's still problems with guaranteeing the correct naming, but we've
always had that problem.
> 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).
Bingo.
> > > 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.
Except for nothing depends on the symbols in uhci.o. Or more correctly,
we need to create a dependancy between "this unique printer" and "uhci
controller". Like I said, it's probably 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.
>
> 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.
I must have misunderstood when you said usbcore would modprobe all of the
HCD's since we know which ones exist because it can statically link them
into the kernel.
> What I'd really prefer is to know that unused drivers will get
> autocleaned, and that "usbd" will load the basic kernel drivers.
Sure.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
