This message is from the T13 list server.
Tom, My point is that these commands have not been in the standard for five years, so complaining about that now will not get a lot of attention from any standards body, in particular T13. So the conversation on that point just looks a bit fruitless. As I suggested to Don, if people want to debate the merits of things like the SEEK command, which T13 is considering, that would make a lot more sense. Or make a proposal for new functionality. Standards bodies are very careful (both in procedure and content) to not be perceived as creating an environment of collusion between competitors, since that can be held to be illegal. The implication is not only that it is hard to get T13 to adopt something, but that it should be hard, and indeed must be hard to actually be legal. That's why a lot of standard committee decisions are taken on a consensus basis, and not a strict majority vote. Sometimes the latter are really needed, but they always introduce risk, and so cannot be used often or for things that a lot of people really feel strongly about. So the default is always to leave things out of the standard - taking no action is always the safest thing for the industry. When something is included, it is often as an option. While this hurts interoperability, it promotes the consensus needed to produce the standard in the first place. As you stated, none of this stops customers from requiring things above and beyond the standard in their own purchasing specifications (indeed, some whole product categories, like reliability and performance, have never been addressed in the ATA standard). Suppliers and customers interact, the result being products people actually buy. Jim -----Original Message----- From: Thomas Colligan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 9:57 AM To: McGrath, Jim; 'don clay'; ata reflector Subject: Re: [t13] Re: ^ 18 R/W Long commands Jim; This is ridiculous, OEMs still require these commands be supported for a number of reasons. The drive suppliers comply to the OEM wishes. At the same time, in the ATA specification it states that these commands, are no longer part of ATA. There are two faces, the face that is presented by HDD suppliers while at T13 and the one in front of a customer. They say state they will still support these commands. So here we have the dilemma. We have individuals making decisions, that ultimately impact their own customers or even those whom have nil as customers. Those whom actual have customers, reassure them, they will still support them. So why the two positions? So, Why not have a single command, with the options, as Jeff summarized in his email. I can see it now every drive supplier would be against any proposal. Its not a cake walk trying to get anything into ATA unless it benefits the drive suppliers. I can here stories now! Everyone, happy except for drive suppliers because they would have to do as their customers ask. What a novel Idea? As Harlan stated it is getting harder and harder to test today's ATA hard drives for a number of reasons. I expect HDD supplier factories are under the same constraints. How do you completely test a 120GB in the time required by upper management, and state that the drive is good. We should be adding new test technologies that allow for a quicker analysis of drive issues. As the capacity of today's HDD increase the more difficult it will be for all of us. Tom Colligan On 3/19/02 6:56 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote: > 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 >>>> >
