[[[Replied-by-CC-to-all with seemingly individual addresses demoted from CC to BC.]]] Hi. May I ask? How wrong are these conjectures:
> [EMAIL PROTECTED] 02/07/02 11:12AM > the SG driver, the mid-level > and the low level drivers should avoid messing > with the details of a SCSI command Agreed fully transparent true and emulated Scsi connections should be a Linux design goal. Looks to me like this design goal is not yet real? In effect, as yet, there is a bit in the Linux Scsi API's, sent down with the cdb, an option bit we can't turn off, a bit whose size as yet is zero. This bit distinguishes "cooked" from "raw" cdb's. By default, this bit says all of Linux cdb's are "cooked". In the real world, to try and talk like Windows, like Mac, whatever works, the low level drivers of emulated Linux Scsi (Ide/ Usb/ 1394/ ...) have to heuristically translate and retry the "cooked" cdb's. > > have the SCSI layer > > send a 36-byte INQUIRY to probe > > if the low-level driver has the 'emulation' flag set ... > Alan Cox <[EMAIL PROTECTED]> 02/07/02 09:44AM > So we need a controller->default_inq_length ? In effect, these are proposals to try and change the default to turn the "cooked" bit on less often - by definition doomed to fail? Can we not instead make the cooked/raw bit explicit? Because Change is Bad for interoperability, passing down more info is our only complete escape. With a cooked/raw bit made explicit in the API, we could simultaneously: 1) Let true Linux Scsi continue to begin life by cacheing the result of a single x 12 0 0 0 FF 0. 2) Let emulated Linux Scsi begin life with an x 12 0 0 0 24 0 like Windows, or with an x 00 0 0 0 0 0 like Mac, or whatever works. 3) Let new Scsi apps ask to send exotic raw cdb's like x 12 0 0 0 FF 0 even to emulated Linux Scsi devices, when their knowledge of the device in question empowers them to take the consequences on themselves. > the cooked/raw bit explicit? If practical Linux legacy considerations preclude adding an explicitly separate bit to the API, .... We could try dreaming up an escape scheme e.g. strip the leading xFF from any cdb that begins with xFF but pass the rest thru unchanged. Want a fully arbitrary 10 byte cdb? Send down 11 bytes total, first xFF and then the 10 you want. > Matthew Dharm <[EMAIL PROTECTED]> > Look, this issue is going to continue to haunt us > Look, this issue is going to continue to haunt us > Look, this issue is going to continue to haunt us You can say that again. :-) Certainly we can expect the heuristics for cooking cdb's to grow worse over time. Designing devices to comply with Windows leaves _indeterminate_ the effect of op x12 cdb's other than x 12 0 0 0 24 0. Test with Windows leaves _indeterminate_ much (all?) of the content of the first eight bytes, including the additionalLength byte at offset 4, the ansiRev at offset 2, the peripheralDeviceType at offset 0, etc. Indeed, we hear designing 1394/FireWire/iLink devices to comply with Windows can leave op x12 flatly unsupported, as was permitted in Scsi-1, or so creatively implemented as to not bother to transfer in the first eight bytes. > > On paper, performing some short INQUIRY > > prior to a normal INQUIRY should not harm. ... > > truncating the additonal length > > parameter to the buffer length provided. ... > > devices that prattle their full INQ data when asked for less ... > > Your device doesn't handle small requests, mine large. Yah. Welcome to the real world of device design by subcontract to people with whom you do not share fluency in any one human language. Pat LaVarre _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
