udev-100 [was: Glibc-2.4]

Bryan Kadzban bryan at kadzban.is-a-geek.net
Mon Sep 18 16:34:19 PDT 2006

Matthew Burgess wrote:
> The only thing that confused me was if and when we need to use the
> plural form of the key names.

We need to use the plural form whenever we want udev to search up the
device tree to make a match.  If (for instance) we're only interested in
the subsystem value for the device udev is looking at, we can use
SUBSYSTEM="xyz".  But if we want to match all devices hooked up to a PCI
bus, directly or indirectly, we have to have it walk the tree.  (No, I'm
not sure why we'd want to do this.  But that's OK.  ;-) )

For instance, a USB-storage device that I have here shows up as
/sys/class/usb_device/usbdev4.3, and udevinfo tells me that the
SUBSYSTEM for that level is "usb_device".  But the SUBSYSTEMS values one
and two levels up are both "usb", and the SUBSYSTEMS three levels up is
"pci".  To match on "pci", we would need to use SUBSYSTEMS.  (If I would
run udevinfo on the next level up, I'd get SUBSYSTEM=="usb" and would
still have to use SUBSYSTEMS=="pci".)

As for the mappings, the manpages imply this is what we need to do:

SYSFS{...}  --> ATTRS{...}
BUS         --> SUBSYSTEMS
ID          --> KERNELS
$sysfs{...} --> $attr{...}


SYSFS{...} matched any sysfs attribute all the way up the tree.  This is
now ATTRS{...}.  I'd guess that in most cases we don't need to search
the tree for this one, but I don't know for sure, so I'll say just dump
ATTRS in for all the SYSFS values for now, to be safe.

BUS searched the tree for a matching subsystem; from the manpage, that's
SUBSYSTEMS now.  (See the USB-storage device above.)

DRIVER searched the tree before; that's DRIVERS now.

ID searched the tree for a matching device node; that's KERNELS now.

$sysfs{...} (as a replacement string) is now $attr{...}.  I'm not sure
why there's no $attrs{...}, though.

I've attached a patch that does all of this; it looks like a few rules
may have gotten missed before.  I also found a couple screwy settings
that have probably been there for a long time; I changed those as part
of the patch as well.  I'll enumerate them below:

1) The KERNEL=="mice" rule.  All items need commas between them; this
rule is missing a comma between GROUP and SYMLINK.  It also should be
SYMLINK+="mouse", not SYMLINK="mouse", in case the user added their own
symlink before 25-lfs.rules.  We don't want to destroy that.

2) lp[0-9] devices on a USB bus.  This needs to be SUBSYSTEMS=="usb"
(plural) to match the BUS=="usb" from before.  Not sure if it really
matters in this case, but better safe than sorry.

3) 26-modprobe.rules: Replace ATTR{...} with ATTRS{...} everywhere;
SYSFS searched up before, so we should probably keep doing that, just in
case it's required.

4) 60-persistent-storage.rules: Likewise.  Also replace a (missed?)
$sysfs{ieee1394_id} in the Firewire device rule that sets ID_BUS, with
$attr{ieee1394_id}.  *Also*, ATTRS{ieee1394_id} will always match "*";
it should test against "?*" to make sure the attribute is set to
something other than the empty string.  (This was a change made several
udev versions ago.)

> Oh, and I left contrib/ alone.  Once the rule_generator rules go in,
> I guess that directory can be removed, right?

Yeah, looks that way.  I would rather use the "standard" rule-generating
rules than Debian's anyway (nothing against Debian, but the udev guys
would like it if the sample rules got wider testing/usage, instead of
everyone coming up with their own duplicate solution -- and I think
Debian is moving to the udev-provided rules anyway).
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: udev-config-udev_100_update-2.patch
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20060918/b5ae7a0a/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20060918/b5ae7a0a/attachment.sig>

More information about the lfs-dev mailing list