udevtest semi-broken

[bryan@linuxfromscratch.org]

Reference: ​http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=117344874927134&w=2

See the last few lines. I'm not sure if that means it won't be supported anymore, or whether it just means it's broken for a few cases. We only use udevtest in one place (and it works there, for now at least):

​http://www.linuxfromscratch.org/lfs/view/development/chapter07/symlinks.html

It's an optional command to run, but I'm guessing people would get confused if udevtest ever starts printing wrong info.

The linux-hotplug-devel message says there isn't really a replacement. All we want to do in this step, though, is get the user the output of each *_id program, and this may not be too hard to get if we have the user run them all manually.

For reference, this is how you get the data out of each of the *_id tools:

/lib/udev/cdrom_id --export /dev/hdX

# note: the argument is a DEVPATH, not a node
/lib/udev/path_id /block/hdX

# only for IDE:
/lib/udev/ata_id --export /dev/hdX

# only for USB:
DEVPATH=/block/sdX /lib/udev/usb_id -x

# only for SCSI (USB, IDE-under-libata, SATA, or real SCSI):
/lib/udev/scsi_id -g -x -s /block/sdX -d /dev/sdX

# probably not applicable to CDs at all:
/lib/udev/vol_id --export /dev/hdX
/lib/udev/edd_id --export /dev/hdX

Thoughts? Other ideas? Or should I just ignore this until udevtest stops working for these devices? ;-) (Again: it does work, at least for now.)

[Matthew Burgess]

I think that LFS has always tried to use the supported tools provided by upstream developers. As udevtest isn't guaranteed to work, I think it'd be better if we gave commands that have stronger chances of success. From the list you give there, I think we'd just need:

# only for IDE:
/lib/udev/ata_id --export /dev/hdX

# for SCSI (including USB, IDE-under-libata, and SATA):
/lib/udev/scsi_id -g -x -s /block/sdX -d /dev/sdX

Running cdrom_id doesn't appear to give me any particularly useful information for writing udev rules here:

/lib/udev/cdrom_id --export /dev/hdc
ID_CDROM=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_DVD=1
ID_CDROM_DVD_R=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_RAM=1

[Matthew Burgess]

So, if we provide example ata_id and scsi_id commands, what should folks with firewire devices use?

[bryan@linuxfromscratch.org]

Firewire: Never used it myself, but according to ​http://www.linux1394.org/faq.php#sbp2, it shows up as SCSI, since "All of these devices comply with a standard called SBP-2 (Serial Bus Protocol-2). They are accessed like SCSI devices in Linux since the sbp2 driver is a low-level SCSI provider." However, that page is talking a lot about kernel 2.4, too, so I have a feeling it may be out of date. I'd still assume SCSI though, at least for the moment.

cdrom_id: No, it's not immediately useful when looking for which values will be used to ID the device. But it does tell the user which symlink "base" names will be used for the symlinks. Here's the mapping, from udev-105's write_cd_rules script:

ID_CDROM:                 /dev/cdromX
ID_CDROM_{R,RW}:          /dev/cdrwX
ID_CDROM_DVD:             /dev/dvdX
ID_CDROM_DVD_{R,RW,RAM}:  /dev/dvdrwX

(Where "X" means "empty string for the first CD-type device, and 1/2/3/4/etc. for subsequent CD-type devices".) I'm not sure how to mark this up into a table in the book (or whether it's even useful information to give the user), though.

[Matthew Burgess]

Well Udev-109 (see #1992) includes a couple of changes to udevtest, so it appears as though it's still being maintained. Given the upstream support for it, I'm now inclined to just accept that udevtest works in our use cases and therefore should still be used. Doing that keeps our instructions simple by using one tool rather than have to choose between 2 or 3 different utilities.

Bryan, would you agree that it's safe enough to close this as wontfix?

[bryan@linuxfromscratch.org]

So it does. That's odd, after the previous posting. Hey, whatever. ;-)

Looking at one of the ​commits that got added to udev-109, I see that they added code to read a bunch of environment variables out of the sysfs uevent file. On 2.6.20.3, the uevent files aren't readable, but I assume that on newer kernels they are (however, I can't find anything in the lkml archives that says this got committed to anyone's tree; hmm).

Anyway, so maybe the kernel will provide all the required environment variables (when userspace reads the uevent attribute) -- if that set of variables is accurate, then starting with v109, udevtest should start being much closer to what will really happen again.

So yes, I'd say wontfix.

[Jeremy Huntwork]

Milestone 6.3 deleted