Richard A Downing wrote: > I still can't see how to hotplug the usb printer though. Can someone > tell me which rules in the lfs set are supposed to moad the usblp > module, and it's module dependencies usbcore, ohci_hcd and ehci_hcd?
Here's what I understand happens: (If this is wrong, someone please let
me know!)
1) The pci bus driver loads, and enumerates PCI devices. Each device
(which includes the USB controllers, the OHCI/EHCI chips) generates a
uevent. But "udevd --daemon" is not running yet (this happens before
init starts, so before any of the bootscripts, because the PCI bus
driver is not a module), so these uevents are lost. Their /sys
directory is still there, though (each uevent corresponds to a directory
being created or removed in /sys, AFAIK).
2) Eventually, the udev bootscript runs and triggers each uevent file in
/sys (including the ones in the directories that were created for the
OHCI and EHCI controllers by the PCI bus driver). This generates a
second uevent for these directories, and these uevents get handled by
udevd, using the rule that should read:
ACTION=="add", SUBSYSTEM=="?*" MODALIAS=="?*", RUN+="/sbin/modprobe
${modalias}"
(which LFS doesn't seem to have!) That rule will load the ehci-hcd and
ohci-hcd modules. (This happens because those modules have aliases set
that match the PCI IDs of the OHCI and EHCI controllers on your
motherboard.)
(The rule that we have has SUBSYSTEM=="usb", which will only load
modules for USB devices. This is wrong -- if the user builds a PCI
device's driver as a module, that module will never get loaded! Note
also that with recent udev versions, it's VAR="?*", not VAR="*" -- the
latter will match even if the VAR environment variable is not set.)
3) The loading of the various modalias modules (ehci-hcd / ohci-hcd in
your case) will enumerate their various buses (if applicable; in this
case it is, since they're USB drivers) and generate more uevents for the
connected devices (the printer). These will run through the same
modalias rule, and thereby get their aliased module (usblp, in your
case) to load.
4) Any driver which creates a handler for a device node (like usblp)
will generate a *separate* uevent for that device node. That uevent is
what the:
BUS=="usb", KERNEL=="lp[0-9]*", NAME="usb/%k", GROUP="lp"
rule is for -- it moves USB devices whose kernel name starts with "lp"
to the usb/ subdirectory, and assigns them to the "lp" group.
------------
This is all assuming that devices are plugged in when the system starts.
If not, then the sequence is different starting with step 3. The device
enumeration in step 3 won't come up with any hardware, so no modules
will be loaded at that time.
But later, when you plug the printer in, the USB HCD driver will notice,
and will generate a corresponding uevent. This uevent will run the
modalias rule (since there will be an alias for the device), which
should load the usblp module. The usblp module loading will create the
uevent for the lp* device nodes, which will match the second rule above
(the one that moves the node into the usb/ subdirectory).
As far as usbcore, I don't know whether anything will load that module
(though according to the source in 2.6.14, any device that's a USB "hub"
class or interface device will load it if the driver creates a uevent
for that device). It may also be a dependency of one of the HCD
drivers, which would also load it automatically. (I just build it in,
myself.)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
