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.
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 TYPE).
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_
> But sysfs provides this data: The main directory of a SCSI device, for pci0000: 00/0000: 00:1e.0/ 0000:15: 00.0/0000: 16:00.0/ host5/target5: 0:6/5:0: 6:0/,
> example
> /sys/devices/
> 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.