> > 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?
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.
> > 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.)
> > 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.)
> > > 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??)
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
