This message is from the T13 list server.
Hale L: > > > Hale Landis 04/11/02 08:27AM > > > I don't want to start that whole discussion ... but ... > > On paper we can say what we like. But back in the real world, ... > ... work just fine ... Atapi mess ... Thought provoking as always, thank you again. The first paragraphs of my http://members.aol.com/plscsi/ftf.html link discuss the significance of the attitude I think I see embodied in the phrase "works just fine". Go build a device according to the existing public standards, and it will mostly work. Agreed. So what. That's not good enough. More specifically, in four points: 1) > you or your company I don't speak for my employer. I don't speak for my employer. I don't speak for my employer. If I did, then my employer would fly me out to T13 meetings more often, donchathink? If we can put that aside, then ... 2) You read SFF 8020i very differently than I do if you think it says C/D I/O don't matter. Maybe the key difference is that I read (and implemented) Scsi2 first ... have you spent more time with Ata? 3) I should learn to say BSY DRQ C/D I/O. You and I don't disagree about what to do when that whole set of bits has an expected value. We're disagreeing only over how recklessly hosts should swallow unexpected values as equivalent to expected values. 4) That http://members.aol.com/plscsi/ftf.html link I gave is my personal effort to get together with other people on the web to distinguish the real from the unreal in the Ansi T10 & T13 publications. By the way, http://members.aol.com/plscsi/ is my effort, across platforms, to make the evil effects of ignoring C/D I/O easy to observe. At this moment, http://members.aol.com/plscsi/ftf.html is my best effort to explain why in Atapi C/D and I/O actually do matter. I even include two hand-drawn PICTURES, and a http://www.dilbert.com/ link. If you want to assert that C/D I/O don't matter, but don't care enough to read my best effort to explain what I'm actually seeing with my own eyes, then I don't see how we can help each other here further. Please remember I agree Atapi hosts have been seen: a) To copy more data In or Out than the host expected. b) To fail look at BSY and DRQ before they look at C/D I/O. I agree vehemently that these are darker evils than ignoring C/D I/O. At http://members.aol.com/plscsi/ftf.html I talk a lot about evil (a) - enough to hope you in particular would find much of what I write agreeable. I haven't yet written in enough Atapi specific text yet to mention evil (b), but I'm sure I'll remember to discuss it when I mention C/D I/O of Atapi specifically. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> Hale Landis 04/11/02 10:35AM >>> This message is from the T13 list server. On Thu, 11 Apr 2002 09:23:00 -0600, Pat LaVarre wrote: >This message is from the T13 list server. >On paper we can say what we like. But back in the real world, here you remain >flat wrong. Since our last discussion, to try and make this more clear, I've >written: >http://members.aol.com/plscsi/ftf.html Pat, if you or our company think the ATA/ATAPI-x standards are incorrect, you or your company need to bring proposals to T13 to change the standards. Sitting on the sidelines and saying T13 and the ATA/ATAPI-x standards are wrong does nothing to help the industry or the customers that expect ATA/ATAPI hosts and devices to follow the standards. For example, telling people that a host side must look at IO and CD when SFF-8020 never said that and when ATA/ATAPI-x has never said that and when we know that many ATA/ATAPI hosts work just fine without ever looking at IO or CD is nothing but confusing to lots of people. It frequently results in host or device designs that don't work correctly, only adding to ATAPI mess... A mess that should not exist after 8+ years of SFF, T10 and T13 work. *** Hale Landis *** www.ata-atapi.com ***
