Stefan Richter wrote:
James Bottomley wrote:
It's all very well to say this, but I think if you look at what udev
does, you'll find that it uses scsi_id to send a VPD inquiry to the
device so it can populate /dev/disk/by-id, so the point is already
conceded
PS: Alas we don't have a practicable way to know how many of the
- doesn't work with Linux but works to some degree with Windows,
- doesn't work with a 2.6 based Linux distro but did work with a
2.4 based distro
kinds of devices are those with this INQUIRY bug or similar bugs.
While non-udev distros slowly went out of fashion on the desktop, there
was a certain frequency of reports of the latter kind of FireWire
devices, but this was before I became aware of that kind of firmware
bug, therefore I don't have any data whether it played a role for these
cases.
Just a small point here. To my knowledge all devices
that understand the SCSI command set will accept a
36 byte INQUIRY (i.e. an INQUIRY with an "allocation length"
of 36). That is a practical consideration since they would
crash on Windows otherwise.
Now scsi_id (and probably other programs of that ilk
(including some of mine)) get excited when they get a
response to a "36 byte" INQUIRY and go onto ask for
VPD page 0x80 (serial number) or page 0x83 (device id)
via an INQUIRY command with the EVPD bit set.
Now if they were clever they would make sure that
the "allocation length" of the _first_ such VPD inquiry
was 36! That way they could have a close look at the
response and if it wasn't valid for a VPD page
(e.g. requested_VPD_page_num != response[1]) then
they would leave the damn device alone **.
<<< Special case: removable media >>>
Since response[1] of a standard INQUIRY has RMB (removable
medium bit) set in its top bit and the rest of the byte
reserved, 0x80 is a possibility. That could give a
false positive when the serial number VPD page is
requested. So try looking for VPD page 0x83 (with
alloc_len=36) first.
** The logic here is that a brain dead SCSI target
interpreter doesn't look at the EVPD bit and can
only handle an "allocation length" of 36. So if
it receives an INQUIRY cdb with the EVPD bit set
it will just respond with its standard INQUIRY
response.
Doug Gilbert
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
