This message is from the T13 list server.
>>> McGrath, Jim 04/12/02 06:37PM >>> Thanks for talking, thanks for listening. > Note that historically the originators of ATAPI never intended for it to be a transport for SCSI commands. And indeed, it was first implemented in hosts in the ATAPI.SYS driver, which in turn is not a layered driver. A number of these issues only become visible only you start implementing ATAPI device support through layered protocol stacks. Yes. > I think many would conclude that ATAPI is not actually cleanly enough defined to allow transport only bridges to operate successfully in all cases. They'd be wrong about AtapiPio. Transport only bridges have shipped in the tens of millions to Scsi from parallel printer port, AtapiPio, and Usb Mass. They are ENTIRELY transparent. > I don't think anyone ever claimed that any T13 document described how many bytes to transfer for a ATAPI PACKET command. That's the whole point. If ATAPI was a transport protocol, then it has no business defining how many bytes are transferred for the command that it is transporting. A transport protocol just concentrates on how many bytes to transfer per block and/or DMA burst. It is up to the command protocol to specify how many bytes should be transported for the command. Here we lost me, sorry. I'd say ... In Scsi, the command protocol at times specifies only the max count of bytes to copy one way. The actual count of bytes to copy results from a real time negotiation. If the host and the device agree over which way to copy bytes, and the device asks to copy less than or equal to what the host asks, then they both agree to copy the min of what they both asked. The job of a Scsi transport protocol, therefore, is to resolve this negotiation and copy the bytes. AtapiPio does this as well as eight-bit parallel Scsi did. How I think of Scsi appears in pictures at: http://members.aol.com/plscsi/ftf.html#scsi http://members.aol.com/plscsi/ftf.html#thirteen > You appear to be contradicting yourself: Sorry, I don't see my apparent contradiction. I'm hearing T13 people tell me but of course always the host and the device agree in advance over how many bytes to copy, else there is an error and what bytes get copied don't matter. If T13 hasn't specified how the host and device do this, I don't see why we should believe this claim. If a host can access a Pio register during Dma, then why can't a host ask to copy more or less bytes in the same or different direction than the device does? > That is, you always know when a pad byte is a pad byte, and you always know when a host overran sending data - since your baseline information is from the SCSI command you transported, and that will always give you the information you need to sort things out. But this isn't true in real life. I agree this is one of the many fantasies published by T10. But go and try it. It doesn't work. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> McGrath, Jim 04/12/02 06:37PM >>> This message is from the T13 list server. Pat, You appear to be contradicting yourself: >> T13 doesn't describe the SCSI command set for any ATAPI device. > This reality doesn't make a T13 claim that T13 specifies how the host and the > device come to agreement over how many bytes to copy which way too very > credible, does it? I don't think anyone ever claimed that any T13 document described how many bytes to transfer for a ATAPI PACKET command. That's the whole point. If ATAPI was a transport protocol, then it has no business defining how many bytes are transferred for the command that it is transporting. A transport protocol just concentrates on how many bytes to transfer per block and/or DMA burst. It is up to the command protocol to specify how many bytes should be transported for the command. In ATAPI PACKET command, that command information comes from the "embedded" SCSI (actually MMC set) commands transported via the PACKET command. And that in turn is defined by SAM and the SCSI command sets - all matters for T10, not T13. With the exception of the odd byte issue and the (documented) provision for devices to accommodate hosts that overrun data transfers because no one bothered to program the host adaptor hardware correctly, all of you questions are as applicable for SCSI as they are for ATAPI - they are issues dealt with by T10, not T13. And since you have to understand these SCSI commands in order to "know" how many bytes should be transferred, the strictly T13 issues are irrelevant. That is, you always know when a pad byte is a pad byte, and you always know when a host overran sending data - since your baseline information is from the SCSI command you transported, and that will always give you the information you need to sort things out. Indeed, ATAPI actually relies on this in order to make itself work. If you want to make a transport only bridge, you have to ignore questions like "how many bytes should be transported in a command" - all the other transports I know of behave in that manner. It is a question for the command level aware endpoints, not the bridges. If you cannot do that, then the complete set of protocols are not layered well enough to allow a transport only bridge - so don't do one. I think many would conclude that ATAPI is not actually cleanly enough defined to allow transport only bridges to operate successfully in all cases. Note that historically the originators of ATAPI never intended for it to be a transport for SCSI commands. And indeed, it was first implemented in hosts in the ATAPI.SYS driver, which in turn is not a layered driver. A number of these issues only become visible only you start implementing ATAPI device support through layered protocol stacks. I don't know if ATAPI should evolve to become a more transport protocol for SCSI commands. What I do know is that is not how it works today - it is a strange hybrid. And changing that will require work in T13, T10, and by implementers (both device and host). And it will take years. It is not a trivial project. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 4:51 PM To: [EMAIL PROTECTED] Subject: Re: [t13] SFF 8020i is dead? This message is from the T13 list server. > > I'd love to hear people evaluate this claim. Does anyone on > > Earth know of Atapi devices that don't put a zero there? ... > Don't know... Good question. One other thought: last I checked (1999?) Microsoft WHQL required SFF, not Ansi. > > Offline I've seen the claim that nearly all actual Atapi > > devices, if intepreted per Ansi, > > TELL the host to use SFF rather than Ansi. Specifically, this > You mean interpreted per T10 MMC-x, correct? Yes Ansi T10 http://www.t10.org/scsi-3.htm ftp://ftp.t10.org/t10/drafts/s2/s2-r10l.pdf Or ftp://ftp.t10.org/t10/drafts/spc2/spc2r20.pdf Or .... On this issue of what a zero means at offset 2 of the data copied by op x12 Inquiry, AFAIK, all the T10 publications agree. > T13 doesn't describe the SCSI command set for any ATAPI device. This reality doesn't make a T13 claim that T13 specifies how the host and the device come to agreement over how many bytes to copy which way too very credible, does it? > T13 only defines the ATA/ATAPI physical > transport and PACKET command protocol. Except T13 left out from AtapiDma the feature of letting the device ask to copy arbitrary counts of bytes that AtapiPio offered. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> Hale Landis 04/12/02 10:52AM >>> This message is from the T13 list server. On Fri, 12 Apr 2002 07:46:25 -0600, Pat LaVarre wrote: >This message is from the T13 list server. >Offline I've seen the claim that nearly all actual Atapi >devices, if intepreted per Ansi, You mean interpreted per T10 MMC-x, correct? Because T13 doesn't describe the SCSI command set for any ATAPI device. >TELL the host to use SFF rather than Ansi. Specifically, this >claim says that ... In response to the standard, start of life, >plug 'n play query of `plscsi -v -x 12 0 0 0 24 0 -i x24`, most >actual Atapi devices copy in x00 as the byte at offset 2. OK. So this is what a certain SCSI subset, the subset we call ATAPI, should do for this command? If T10 does not recognize this subset then what does that mean? >Ansi T13 had no comment on what this means, last I checked. Again T13 doesn't have anything to do with SCSI command sets. For SCSI devices using the ATA/ATAPI interface as the SCSI physical transport layer, T13 only defines the ATA/ATAPI physical transport and PACKET command protocol. >Ansi T10 says this is an op x12 Inquiry of up to x24 bytes. >(That's close to real - it should copy in x24 bytes always.) >Ansi T10 says x00 at offset 2 means the device "may or may not" >comply with any particular Ansi standard. OK. Sounds like a prefectly valid thing for T10 to say. >SFF says SFF-compliant devices shall put a x00 there. OK. I'm sure that is because SFF-8020 was an attempt by a few individuals to redefine SCSI to their way of thinking. I think we can safely say these people failed, SFF-8020 is now very obsolete. ATAPI device should be implemented according to the appropriate SCSI command set documents, such as MMC-x. That means such device would not be putting 0x00 in this Inquiry data byte. >I'd love to hear people evaluate this claim. Does anyone on >Earth know of Atapi devices that don't put a zero there? Don't know... Good question. *** Hale Landis *** www.ata-atapi.com ***
