Richard A Downing wrote:
I'm sorry I started this again now. I have to say I am more confused
than ever. Do the guys (I use the term loosly, as 'imbeciles' seems
more appropriate right now) upstream have any idea of the difficulties
they are creating by this almost undocumented mess?
No, the major part of the mess comes from the premature desire to remove
the hotplug package before upstream provides a patchless way to do so
and doesn't declare it obsolete for at least a month (as happened with
udevsynthesize).
I didn't have a clue how to answer Alex's question. Where (or when) is
the document you read to find out. (anyone replying 'read xyz
mailinglist archives' may fall on his sword without further ado...)
Enough information is contained in my message that contains the
question. The key phrase is that one hotplug event corresponds to one
directory in sysfs. I assume that you are able to find entries in your
sysfs that correspond to each of your devices.
For a USB printer with linux-2.6.14-rc4 there will be the following
hotplug events (recorded with udevmonitor --env):
First event:
UEVENT[1130296679] add@/devices/pci0000:00/0000:00:07.2/usb1/1-2
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-2
SUBSYSTEM=usb
SEQNUM=919
PHYSDEVBUS=usb
PHYSDEVDRIVER=usb
Udev does nothing in response to this.
Second event:
UEVENT[1130296679] add@/devices/pci0000:00/0000:00:07.2/usb1/1-2/1-2:1.0
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-2/1-2:1.0
SUBSYSTEM=usb
SEQNUM=920
PHYSDEVBUS=usb
DEVICE=/proc/bus/usb/001/005
PRODUCT=4b8/5/100
TYPE=0/0/0
INTERFACE=7/1/2
MODALIAS=usb:v04B8p0005d0100dc00dsc00dp00ic07isc01ip02
Udev doesn't create any device in response to this by default.
In the fixed LFS setup with udev_run_hotplugd (but not in the current
setup), it would run /sbin/udev_run_hotplugd, and eventually pass the
whole lot of strings to /etc/hotplug/usb.agent as the environment. This
agent would look for 04b8/5/0100 in
/lib/modules/2.6.14-rc4-home/modules.usbmap and load usblp.
In the hotplug-less setup, the following rule should be present:
ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $modalias"
or
MODALIAS=="*", RUN+="/sbin/modprobe $modalias"
With this rule, udev would attempt to "modprobe usb:v04B...." which
resolves to usblp in /lib/modules/2.6.14-rc4-home/modules.alias
OK, now we have either "usblp loaded by udev or hotplug", or the
"already-loaded or compiled-in" case, or "no usblp driver" case. For the
first two cases, the usb bus code in the kernel binds the usblp driver
to the device. This produces the third event:
UEVENT[1130296679] add@/class/usb/lp0
ACTION=add
DEVPATH=/class/usb/lp0
SUBSYSTEM=usb
SEQNUM=921
PHYSDEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-2/1-2:1.0
PHYSDEVBUS=usb
PHYSDEVDRIVER=usblp
MAJOR=180
MINOR=0
Udev creates /dev/usb/lp0 in response to this.
With 2.6.14 kernels (but not 2.6.13), the following additional hotplug
event is also present, even if usblp driver is not available:
UEVENT[1130296679] add@/class/usb_device/usbdev1.5
ACTION=add
DEVPATH=/class/usb_device/usbdev1.5
SUBSYSTEM=usb_device
SEQNUM=922
PHYSDEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-2
PHYSDEVBUS=usb
PHYSDEVDRIVER=usb
MAJOR=189
MINOR=4
With the following rule, udev creates /dev/bus/usb/1/5 node for libusb
use (needed for scanners and cameras, useless for printers):
SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev}
B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c", GROUP="usb"
What EXACTLY was wrong with MAKEDEV? So it created a few extra nodes
and didn't create /dev/agpgart and /dev/hda9. Missing devices were the
only valid complaint AFAIK. Udev's ability to handle hot-plugged devices
was considered a not-very-needed feature.
But, as you see, udev didn't really solve the missing-device problem
because it created a missing-module problem.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
