Comment # 22 on bug 922405 from Alan Ott

(In reply to Hannes Reinecke from comment #21)
> Which is precisely what we do nowadays; with the most recent sg3_utils we're
> just looking at the respective sysfs attributes, and will not query the
> device itself. The most recent 55-scsi-sg3_id.rules has eg:
> 
> # SCSI EVPD page 0x80 values
> KERNEL=="sd*[!0-9]|sr*", ENV{ID_SCSI}=="1", ENV{ID_SCSI_SN}=="1",
> IMPORT{program}="/usr/bin/sg_inq --export
> --inhex=/sys/block/$kernel/device/vpd_pg80 --raw"
> KERNEL=="sd*[!0-9]|sr*", ENV{ID_SCSI}=="1", ENV{ID_SCSI_SN}!="1",
> IMPORT{program}="/usr/bin/sg_inq --export --page=sn $tempnode"

Sorry, I read it wrong. You are right. So right now, the new version does:
1. If /sys/block/$kernel/device/inquiry exists, then assume:
   /sys/block/$kernel/device/vpd_pg80
and
   /sys/block/$kernel/device/vpd_pg83
both exist (or can't exist) and use them....

2. But if /sys/block/$kernel/device/inquiry doesn't exist, then call sg_inq to
try to get the data from the device directly.

what's the point of #2? What is the use case where this matters? When will a
device _not_ have an inquiry sysfs node? If a device doesn't have an inquiry
node (meaning the INQUIRY requests to the device by the kernel have all
failed), do we really think sending VPD inquiries from user space is guaranteed
to not make things worse?

The reason I'm asking #2 is because I'm skeptical that there is _any_ reason to
be issuing scsi commands from user space (other than testing and debugging).
The kernel goes to great lengths to get the proper information from the device,
working around many types of buggy devices. The data is either there and can be
read from sysfs, or the kernel is unable to get the data, in which case user
space shouldn't try it, because you might either get bad data or lock up the
device.

In my opinion, I'd remove all sg_inq calls in this sysfs file. Either the
kernel has read the data or the kernel can't read the data. User space should
trust the kernel to interact with scsi devices.

> 
> ie we're trying to read from /sys/block/sdX/device/vpg_pg89 (if existing)
> or, if this doesn't exist, use the sg_inq program to read from device.
> 

You're reading from /sys/.../vpg_pg83 if sys/.../inquiry exists.

why not just read from sysfs and call it done? I reiterate that calling scsi
commands from user space when the kernel has already decided that these
commands aren't going to work doesn't make sense.

> We might need to update the sg3_utils package in Leap, though.

Please do. That would seem to fix the immediate problem.

Alan.