Comment 3 for bug 399319

On 28.07.2009 15:00, Martin Pitt wrote:
> 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).

Thanks for the clarification!

>
>> 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/...

Just tried that: It returns exactly the same data for the given device
as --export-db. --attribute-walk returns all attributes, but includes
parent devices too, so we would get a lot of redundant stuff.

>
> 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.
>

Well, we would need to read sysfs attributes only for SCSI devices, and
I think the average system will have less than 10 devices that use the
SCSI subsystem, including disks, CD drivers, USB memory sticks etc.

But: Since checkbox is written in Python: Do we have Python bindings for
libudev?

Abel