This message is from the T13 list server.
Don, I was wrong in thinking that READ LONG/WRITE LONG was tied into the recent addressing changes (I got the timing confused in my mind with the SEEK command, which has just been proposed to become obsolete). In reality READ LONG/WRITE LONG were made obsolete in ATA-4 back in August of 1997 (actually in revision 5 of that document in June of 1996). So they have not appeared in ATA-4, ATA-5, or ATA-6 (or the upcoming ATA-7). It has not been in a draft document for more than 5 years. Every one of those standards have advised hosts not to use that command anymore, since devices are compliant while only returning a command aborted in response to the command. Indeed, they only appear in ATA-1, ATA-2, and ATA-3. ATA-1 and ATA-2 are withdrawn standards (i.e. they no longer exist except as historical footnotes), so the only standard they are mentioned in is ATA-3. So the issue is rather academic (unless, once again, people have a new proposal on some new functionality to make). The current issues are obsoleting the SEEK command and CHS addressing mode. Jim -----Original Message----- From: don clay [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 2:27 PM To: ata reflector Subject: [t13] Re: ^ 18 R/W Long commands This message is from the T13 list server. Jim, I have over 26 years of experience with multiple disk drive companies, both big box and in ATA drives with long runs of service with two different companies. I have designed ATA ASIC's and written the code for them. I have been involved in the development of ATA drives since mid 1986. So I have designed the R/W Long command in several ASIC's and then written the code for those commands. Both the code and the ASIC's have shipped successfully in very large volumes. I have been intimately involved in the testing and development of all of these drives in very many different ways. I have worked closely with many different customers and understand how they used to want drives tested and how they want them tested in the present. Furthermore, I have worked very closely with other OEM's in the development of their ASIC's for the ATA Interface. That technology also shipped in very large volumes. It has been my experience that you are wrong in this matter both on the hardware and firmware side of this discussion. I have provided examples supporting my position and could supply more if necessary. These assertions are based on actually designing and testing ASIC's, doing the code for them, and then designing tests for them. I entered this thread because the ATA committee is continually short sighted in it's approach to backward compatibility. It has repeatedly acted without considering the whole of the ATA interface community. This has been true since the inception of this standards effort, which I also witnessed first hand. This thread began with several people complaining about the obsolescence of the R/W Long commands. The committee obviously did not poll the constituency of the ATA community prior to making the decision to obsolete the R/W Long commands as several people have noted. Obsoleting a command, as I've stated many times prior to this, subjects companies that are using such commands to the whims and politics of this committee. People should not have to come to these meetings out of self defense. People who are on the committee should have the responsibility to look at the big picture and all of the members on it when considering changes. That would be a good use of this reflector. Your last paragraph is an example of that. Burden of proof???? The ATA committee should be comprised of members who are going to exercise due dilligence prior to making a change. It is totally irrevalent how the R/W Long command is being used. People are using it. And that is burden of proof enough. don clay 3/19/02 1:23:57 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: > >Don, > >First, not all opinions are equal. I've worked at a disk drive company for >15 years, and I know whereof I speak. Perhaps more importantly, a lot of >folks on T13 are equally well educated on these sorts of issues. You keep >on asserting no there are costs, despite the facts that they're been >outlined to you. You are just not listening - so I'll stop talking. > >Second, the burden of proof is always on people advocating change - in this >case to add READ/WRITE LONG back into the standard. My (constructive) >suggestion has been to put together a proposal that accomplishes what people >want (whether that's really testing ECC, error injection, marking sectors, >etc...) and submit it to T13. Or even wait until it is published and offer >a public comment. If you are not willing to make the effort, then it's >obviously not a very important topic for you. > >Jim >>>
