http://bugzilla.suse.com/show_bug.cgi?id=922405 http://bugzilla.suse.com/show_bug.cgi?id=922405#c23 --- Comment #23 from Hannes Reinecke <hare@suse.com> --- (In reply to Alan Ott from comment #22)

(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?

Backwards compability. The vpd sysfs entries went into the kernel around 3.15, but have the problem that a non-existing vpd sysfs entry can mean either we're running on an pre-3.15 kernel _or_ that the VPD pages are not supported. The 'inquiry' sysfs entry went into the kernel around 4.4, and will always present. So if we check for the 'inquiry' string we _know_ that the vpd sysfs attributes are implemented, and can rely on these values. If the 'inquiry' sysfs entry is not present we cannot tell if the sysfs vpd entry should be present, so we have to issue an ioctl to get the correct value. Which means we can run this rule on any kernel, and we will make the best effort to not issue any ioctl.

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.

See above. This reasoning is true for post-4.4 kernels. It is _not_ true for earlier kernels. But as we don't have any possibility to restrict the usage of the udev rules to particular kernel versions we have to ensure it'll work on any of those.

...

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.

See above. We cannot guarantee that the vpd sysfs page always exists. (Note: this is the upstream package, and not a Leap-specific one). -- You are receiving this mail because: You are on the CC list for the bug.