This message is from the T13 list server.
I agree that ATAPI should just be a transport for SCSI commands over ATA. However, SFF8020 explicitly took steps to make that impossible (I was at the meetings - there was a lot of anti-SCSI bias that led to active steps to distance ATAPI from SCSI). Ever since many people have desired what you have articulated. But the past continues to haunt us to this day. Specifically, ATAPI does not conform to SAM, which is the unifying document for all transports that would take SCSI across other physical interfaces. There are many ways to fix this, but no one has done this to my knowledge. And as Hale points out, this is a T10 committee issue, not a T13 committee issue (both SAM and the SCSI command set are under the jurisdiction of T10). Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Friday, April 12, 2002 11:19 AM To: [EMAIL PROTECTED] Subject: Re: [t13] but both host and device know This message is from the T13 list server. > > In my opinion, trying to think of Atapi as anything other than > > yet another Scsi transport shows a lack of understanding of the > > basics of I/O subsystem design for a plug 'n play O.S. This I stand by. I hear an accepted rule of programming style for interfaces is to change nothing unless you change it dramatically. SFF clearly violate this rule in how they slightly redefine Scsi. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> Hale Landis 04/12/02 11:17AM >>> > (See my previous email about the Inquiry command)... Dunno Which you mean, sorry. > Please stop trying to make this into a T13 ATA/ATAPI problem. > And it probably isn't a T10 problem either. http://members.aol.com/plscsi/ftf.html presents this as an observable difference among forms of Scsi-over-whatever. Residue accurate to the byte is a competitive advantage held by AtapiPio, generic Usb Mass, classic fully-handshaked parallel Scsi ... Atapi Dma allows reporting residue, but the accuracy diminishes with burst rate. Agreed, one competitive disadvantage among many doesn't qualify as a "problem". We can't credibly say residue accurate to the byte has no value. The public change histories of Scsi-over-whatever show this is a feature people add later if they overlook it initially. What's weird about Atapi is that residue is growing inaccurate, despite once having been implicitly supported. > ALL ODD TRANSFERS WILL > BE ROUNDED UP TO THE NEXT EVEN VALUE. This is just not true. Microsoft Win95B AtapiPio crashes if you try an odd length transfer. Microsoft Win98 AtapiPio copies the odd length no worries. I imagine, though I haven't checked lately, that the follow-on Win versions retained this fix. Within Atapi, it's only AtapiDma that rounds up an odd length. Yes 2 * N blocks clock across the bus even in AtapiPio. But AtapiPio reports the residue in advance of the transfer, thus leaving the host is free to choose to access an extra byte of its memory or not. http://members.aol.com/plscsi lets you look to see what these kinds of things actually do at your own desk. As yet that's easy only for Dos thru WinMe, but we've got proof-of-concept on Win2K/XP, Linux, and Apple Open Firmware boot Forth. Volunteers are welcome. > Are you trying to ... redefine ATA/ATAPI or SCSI > to your way of thinking without bringing proposals to T13 or T10? I hope NOT. I know of no deeper evil in Atapi than the SFF penchant for making what were active hi bits active lo, making what was required optional, etc. I am trying to write down on paper how laptop/desktop/personal Ata/pi really does work, in contrast to the pretty fantasies that T10 & T13 have a long history of publishing. This reality is most heavily influenced by what Microsoft implements, but Apple, Linux, and co. also make significant contributions. Device makers have little influence. A single employee's spare time has still less influence. If and when I get straight a way to talk about what's really going on - http://members.aol.com/plscsi/ftf.html is my first try - then sure next I'll try to find someone with money to pay for the air flights it might take to persuade Ansi to at least make reality optional. No reality is not negotiable. It's real. It's over already. I imagine publishing a paper to try and tell Microsoft what to do is rarely effective. I'd say Usb Mass is one of the few exceptions, and even there I hear Microsoft implemented their own alternative for reporting residue. More specifically, when residue is positive, I hear they report bytes clocked across the bus, not bytes blessed by the dCSWDataResidue, but that can be the same for data copied In if you design your device knowing this, because Usb bus clocks are precise to the byte. > I think the actual problem here is the wish to make > X-to-ATAPI bridge devices that are super cheap and somehow cheat > and don't perform the true task that needs to be performed. Certainly that's my root motivation. I want to design one bridge and be done, not redesign it for every new Atapi device connected to it. Personally I mostly enjoy learning, but I like to get paid to have fun. It never occurred to me that storage folk wouldn't universally be deeply concerned about counting precisely how many bytes to copy which way, not til some considerable time after I joined the industry in 1994, and I began to reflect on my personal history of pain. The best solution I've seen is Ata. If it's a block device, then make everything be a multiple of blocks, and these niggling issues mostly vanish, perhaps because people do an ok job of testing block write/read. >>> Hale Landis 04/12/02 11:17AM >>> This message is from the T13 list server. On Fri, 12 Apr 2002 08:33:01 -0600, Pat LaVarre wrote: >This message is from the T13 list server. Hale said: >> In my opinion trying to make ATA/ATAPI >> work like some other interface >> shows a lack of understanding >> of the basics of ATA/ATAPI. Then Pat said: >In my opinion, trying to think of Atapi as anything other than >yet another Scsi transport shows a lack of understanding of the >basics of I/O subsystem design for a plug 'n play O.S. (See my previous email about the Inquiry command)... But here again is the confusion I see in your statements. If a system has a USB interface and you attach a SCSI device (that is really a bridge) then that device needs to conform to the SCSI standards for that type of device. That means that the Inquiry byte would not be 0x00 even if the real device behind the bridge was an ATAPI device that had 0x00 in that Inquiry byte. IN OTHER WORDS: THE USB-to-ATAPI BRIDGE MUST PERFORM THE CORRECT AND PROPER COMMAND SET EMULATION! Please stop trying to make this into a T13 ATA/ATAPI problem. And it probably isn't a T10 problem either. The problem is the failure of these bridge devices to perform their job correctly! >There's no standard place to claim, for example, that a >particular Atapi device will copy In 6 bytes via Atapi Dma if it >would have copied In 5 bytes, given precisely the same -x 12 0 0 >0 05 0 "Inquiry of additionalLength" command. The ATA/ATAPI interface is 16-bits wide. ALL ODD TRANSFERS WILL BE ROUNDED UP TO THE NEXT EVEN VALUE. This is just one of those things we know, sort of like we known the sun rises in the east. A properly implement X-to-ATAPI bridge needs to know this and handle it, especially if the X side can't handle that extra pad byte. Again, the bridge must be properly implemented and do its job correctly! >http://members.aol.com/plscsi/ftf.html >exists to present a >scheme for comparing one Scsi transport with another, sorted to >present the actual consequences of this lack of correlation from >the most commonly to the most rarely observed. Just curious... Are you trying to do what those original SFF-8020 people tried to do? That is redefine ATA/ATAPI or SCSI to your way of thinking without bringing proposals to T13 or T10? (Sure sounds that way to me.) But I think the actual problem here is the wish to make X-to-ATAPI bridge devices that are super cheap and somehow cheat and don't perform the true task that needs to be performed. That's fine and maybe there is a big market out there and such products would be very sucessful... But... Trying to change 8+ years of history and ignoring the approved and established interface standards in order to make these bridge devices is probably doomed to failure in the long run. Of course the business model for success here is well known... Just form a "secret society" with a strongly worded NDA, hold secret meetings, issue glowing press releases about how great things will be and ... (need I say more?) *** Hale Landis *** www.ata-atapi.com ***
