This message is from the T13 list server.
I always ask people the question "what would you do with the command if you used it." For instance, REQUEST SENSE does not help much if just always retry commands on errors anyway (it does help if you are creating a log of errors for later viewing by a service type of guy). TEST UNIT READY makes a lot of sense for removable media, but a lot less for a HDD (just do a READ a few times to get it out of low power mode and/or wait for spin up). MODE SENSE without MODE SELECT is just a diagnostic. etc... Too many people just read the standard and implement everything in sight. If you can focus your efforts on fewer things, then you'll end up with a better product (everything else being equal). Alas, us poor drive guys are stuck implementing a lot of this stuff, but host guys have more freedom. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 3:17 PM To: [EMAIL PROTECTED] Subject: [t13] the minimal usable Scsi/Atapi op set 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/
