On Fri, Jun 02, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> > > As it would be. The table would be what "modprobe" consults, which
> > > is set up as aliases ... something like 'pci-controller-0c-0310' (OHCI)
> > > or 'pci-controller-00-0310' (UHCI). Something in the PCI init sequence
> > > would request_module() to get drivers for unclaimed PCI controllers.
> > > There may be some reason not to have PCI code do that yet, but that's
> > > not the only way to improve things a lot for USB.
> >
> > Remember, people want this to load on demand when the device is used,
> > not during PCI init.
>
> I confess you've lost me. What UNIX device is a USB Host Controller?
There is none. I think you're understanding the problem pretty well.
There's a dependancy chain, there is usually a device which does have a
device node to trigger the loading (/dev/sda for the USB floppy).
> 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 related fix would have usb_init (or usb_module, why are there two
> > > names for one function??) learn that since each HCD can be compiled as
> > > a module, it should request_module("usb-ohci") etc as needed. Without
> > > trying that, I'd expect it would let a userland "modprobe usbcore"
> > > (likely from /etc/rc) trigger full USB init ... including post-installs
> > > to mount the usbdevfs and start the usbd. (Some work is needed to get
> > > the modprobe to fail cleanly when no USB controllers are registered.)
> >
> > The user may not want the usb-ohci driver loaded everytime if they don't
> > actually have the HC on the system.
>
> 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.
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.
> > > Given that, and PCMCIA services knowing how to "modprobe usb-ohci",
> > > I think most current configurations would be handled as cleanly as
> > > the 2.4 distributions are going to need for a long time: update RC
> > > scripts, PCMCIA configs, and modules.conf ... and get 'usbd' alive!
> >
> > I suppose PCMCIA is different in that when a user inserts a card, they
> > want to use at that moment.
> >
> > This may be true for deviecs on the USB bus as well, but I'm not sure if
> > this is necessarily true for the HC on most non PCMCIA machines.
>
> Like I said, "modprobe usbcore" in /etc/rc could work in other cases.
> (Or an rc-less solution can be based on what PCI controllers exist.)
I'm just saying that may not be what the user wants. They probably want
it to be loaded when they use it, not when the system starts.
> > > > The new PCI code has something like this, but the driver must register
> > > > itself first. It's the old chicken and the egg problem.
> > >
> > > That'd come up when using the PCI device for booting. Workaround
> > > is to not to use modular drivers (like OHCI/USB-Ethernet/...) there,
> > > though I'm not sure whether the USB code now handles that case.
> > >
> > > Or is there some other issue?
> >
> > Not using modular drivers is not acceptable. The purpose of modules is
> > to load the module on demand while the system is running and we should
> > make sure that we do that. If we don't, there's very little reason for
> > modules at all.
>
> It sounds like you're saying it's possible to modprobe the driver
> used to access the root filesystem ... when that filesystem isn't yet
> mounted and /sbin/modprobe and /modules/ aren't available. That seems
> rather impossible to me, so likely that's not what you were trying to
> describe! (LILO doesn't know about USB mass storage yet, does it??)
LILO doesn't and it probably shouldn't know about it. Look into EFI. But
that's off topic.
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.
This is a very desirable feature. When I use my USB still camera, I want
the USB core and HC module to load as well as a possible kernel driver
for that device (userspace vs kernelspace driver).
Loading the HC at boot time obviously isn't what was wanted.
Unfortunately getting this behaviour may be difficult because of devices
like keyboards, etc which don't have device nodes to dynamically load
devices.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
