#1972 closed task (wontfix)
udevtest semi-broken
Reported by: | bryan@linuxfromscratch.org | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Book | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description
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.)
Change History (6)
comment:1 by , 18 years ago
Milestone: | → 6.3 |
---|
comment:2 by , 18 years ago
So, if we provide example ata_id and scsi_id commands, what should folks with firewire devices use?
comment:3 by , 18 years ago
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.
comment:4 by , 18 years ago
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?
comment:5 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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.
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:
Running cdrom_id doesn't appear to give me any particularly useful information for writing udev rules here: