This message is from the T13 list server.
>>> McGrath, Jim 03/21/02 03:28PM >>> > Most things in SCSI are optional ... I always advise > host guys to cut the fancy s**t > and just stick to the basics (INQUIRY, READ, WRITE). Interesting as always, thank you. Me, in device design, I duck this question by implementing precisely what the people before me implemented. (Me, I knew nothing of low level storage interfaces until very recently i.e. 1994.) At http://www.t10.org/scsi-3.htm I see the Rbc effort tried to shrink Scsi. I hear this effort stumbled in significant ways, e.g. they changed the op x12 Inquiry byte 0 & x1F peripheralDeviceType to not be x00 DirectAccessStorageDevice ... whoops. > stick to the basics (INQUIRY, READ, WRITE). I hear hosts are divided over whether to begin with Scsi (aka Atapi) op x12 Inquiry, op x08 Read(6), op x28 Read(10), or op x00 TestUnitReady. I've seen people define The Basics as read/write only of the first 2TiB @ 0.5KiB/block: [x12] Inquiry [x28] Read(10) [x2A] Write(10) Then they add x25 ReadCapacity and x1A ModeSense(6) as extension to x12 Inquiry. They add x00 TestUnitReady and x2F Verify to help make rare the situation of a device copying in less data than the host expects. They add x03 RequestSense why not, and to my surprise, then some add x2E WriteVerify(10) and even x04 FormatUnit. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> McGrath, Jim 03/21/02 03:28PM >>> This message is from the T13 list server. Most things in SCSI are optional. That's why they got into the standard ("please vote for it - afterall, you don't have to implement it if its optional") but it does make a mess out of planning for what is "really" supported. That's why I always advise host guys to cut the fancy s**t and just stick to the basics (INQUIRY, READ, WRITE). Trying to use everything in the standard is like writing a memo using every font on the PC - very artistic, but hardly very usable. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 1:09 PM To: [EMAIL PROTECTED] Subject: Re: [t13] X-to-ATA bridges and R/W LONG This message is from the T13 list server. >>> Hale Landis 03/21/02 11:27AM >>> > Can anyone answer... > Do USB-to-ATA bridges support R/W LONG? > Do 1394-to-ATA bridges support R/W LONG? I'm not sure I understand the question ... I think I remember in Scsi r/w long is a standard device design OPTION, not a standard device feature. So by people can only answer device by device whether they chose to implement the option or not? Any fully transparent Usb-to-Atapi bridge, or a fully transparent Ata over whatever bridge, supports r/w long together with everything else possible, by the definition of "fully transparent". I did see that the last two Usb-to-Ata and 1394-to-Ata devices that I touched in detail personally (Summer, 2001) translated optional Scsi ops x3E/3F Write/Read Long to Ata ops x23/33 Read/Write Long after getting Ata op xEF:44 SetFeatures VendorUniqueLongBlockLength to pass and fetching xEC Identify data to discover the VendorUniqueLongBlockLength. I didn't appreciate that people found the T13 specs vague here, I'll have to go dig in now. > Do 1394-to-ATA bridges support R/W LONG? I have never seen one. Did you mean you have never seen a 1394 to Ata bridge or did you mean to say you know of bridges that do not pass thru Read/Write Long? > Does "serial ATA" support the ATA R/W LONG command protocol? I'm even more stunningly ignorant of Ata than I am of serial Ata ... so I'm sure I don't really know what this query means. Serial Ata is a bridge design, yes? Knowing just that much, given a block size K, if serial Ata can't copy N * 2 bytes just because N * 2 != K, then (a) serial Ata can't talk Atapi and (b) serial Ata ain't a transparent bridge design. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/
