Re: no INQUIRY from userspace please
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 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
no INQUIRY from userspace please (was Re: [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE)
Mike Anderson wrote: A number of user apps like lvm scanning that execute media access commands already have filter capability to filter devices that one does not want to scan. Another class of device scanners just use inquiries which are not effected by the passive state (though some could probably use udevinfo and reduce the amount of repeated SCSI inquiries execute on the system. To expand on this: At least on desktop systems and SOHO server systems, userspace should _never_ issue INQUIRY. There are too many broken firmwares out there which assume that there will never be more than one INQUIRY sent. They start to return garbled data or crash if they get a second INQUIRY. -- Stefan Richter -=-==--- --=- --=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no INQUIRY from userspace please (was Re: [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE)
--- On Thu, 2/7/08, James Bottomley [EMAIL PROTECTED] wrote: This is all a tradeoff. If you want userspace *never* to issue raw SCSI commands like INQUIRY, we're going to have to provide the needed information from the kernel via sysfs ... including VPD strings. This is something we've always shovelled off into userspace before. What if a user-space application client _does_ send an INQUIRY to a device anyway? It would probably be better to preserve application client behaviour and simulate/emulate n-th INQUIRY, after the 1st for such broken device firmwares that break on any subsequent INQUIRY. Possibly in the LLDD or via blacklisting in the mid-layer. Luben - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no INQUIRY from userspace please
(adding Cc linux-hotplug) James Bottomley wrote: On Thu, 2008-02-07 at 11:08 +0100, Stefan Richter wrote: Mike Anderson wrote: A number of user apps like lvm scanning that execute media access commands already have filter capability to filter devices that one does not want to scan. Another class of device scanners just use inquiries which are not effected by the passive state (though some could probably use udevinfo and reduce the amount of repeated SCSI inquiries execute on the system. To expand on this: At least on desktop systems and SOHO server systems, userspace should _never_ issue INQUIRY. There are too many broken firmwares out there which assume that there will never be more than one INQUIRY sent. They start to return garbled data or crash if they get a second INQUIRY. 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 (and I think looking at a recent camera crash that seems to have been precipitated by this, it's already causing us problems). This is all a tradeoff. If you want userspace *never* to issue raw SCSI commands like INQUIRY, we're going to have to provide the needed information from the kernel via sysfs ... including VPD strings. This is something we've always shovelled off into userspace before. Well, it's definitely awkward to have to deal with less than perfect firmwares. But there is still potential to optimize udev based on what we already have in sysfs. For example, on Gentoo I see calls of scsi_id and usb_id for FireWire disks (by udev? by HAL? I don't know), even though udev actually also reads the FireWire driver specific sysfs attribute with the target port ID and LUN. I.e. udev knows where to look but calls pointless helpers anyway. (BTW, how about sysfs attributes for the target port identifier and for the logical unit identifier --- at transport independent sysfs paths --- to simplify userspace's life? What else?) -- Stefan Richter -=-==--- --=- --=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no INQUIRY from userspace please (was Re: [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE)
On Thu, 2008-02-07 at 11:08 +0100, Stefan Richter wrote: Mike Anderson wrote: A number of user apps like lvm scanning that execute media access commands already have filter capability to filter devices that one does not want to scan. Another class of device scanners just use inquiries which are not effected by the passive state (though some could probably use udevinfo and reduce the amount of repeated SCSI inquiries execute on the system. To expand on this: At least on desktop systems and SOHO server systems, userspace should _never_ issue INQUIRY. There are too many broken firmwares out there which assume that there will never be more than one INQUIRY sent. They start to return garbled data or crash if they get a second INQUIRY. 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 (and I think looking at a recent camera crash that seems to have been precipitated by this, it's already causing us problems). This is all a tradeoff. If you want userspace *never* to issue raw SCSI commands like INQUIRY, we're going to have to provide the needed information from the kernel via sysfs ... including VPD strings. This is something we've always shovelled off into userspace before. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no INQUIRY from userspace please
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. -- Stefan Richter -=-==--- --=- --=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
