Comment 2 for bug 399319

Revision history for this message
Martin Pitt (pitti) wrote : Re: [Bug 399319] Re: Remove the HAL dependency from Launchpad HWDB and checkbox

Abel Deuring [2009-07-27 16:30 -0000]:
> The only major problem I found is related to some SCSI devices: While
> the udevadm output contains the SCSI vendor and model strings for disks
> and CD drives which use the kernel's SCSI layer (.i.e., not only real
> SCSI devices, but also ATA drives), this data is missing for SCSI
> scanners. I assume that it is as well missing for the SCSI device type
> "processor" (used for some Epson and HP scanners, and for example for
> tape robots.)

Some clarification is in order here, I think. There are two kinds of
information you can process with udev: (1) data from sysfs, which
rules can match on, but aren't stored in udev itself (example:
"vendor", "idProduct", etc.), and (2) additional properties which you
can attach to devices in rules with ENV{VAR}="value". Properties are
stored in udev itself, and that's what you get with --export-db".
export-db will _not_ dump the sysfs properties!

Properties are mainly used to attach additional information to devices
which aren't directly exported by/related to the hardware, such as
"this is a device supported by libgphoto" (ID_GPHOTO2), or the
partition type of a drive (DKD_PARTITION_TYPE).

> But sysfs provides this data: The main directory of a SCSI device, for
> example
> /sys/devices/pci0000:00/0000:00:1e.0/0000:15:00.0/0000:16:00.0/host5/target5:0:6/5:0:6:0/,
> contains the files "vendor", "model" and "type", which provide exactly
> the data we need.
>
> These directories are easy to find: If a udev path name ends with
> "/scsi_generic/sgN" (where N is a number), replace this string by
> "vendor", "model", "type".

It's certainly possible to directly read sysfs for the information you
need. Another option is to iterate over the device paths and use

  udevadm info --query=all --path=/devices/...

which will give you both the properties as well as the sysfs
attributes. For performance reasons you might want to use libudev
instead of calling udevadm 200 times, though.