This message is from the T13 list server.
In march, 3rd 2002 I posted a question that timidly asked someone who had the patience and time to answer, why read/write long commands were discarded from AT/A-4 on and if it could become available again. Today, 10 days after, people discussed a lot and even argued about this. It seems that some people see that a HDD exists to serve people. A feature already developed and tested should costs less to be kept than the consequences of discarding it, as Don properly said. Not all the real world computers are brand-new using the ultimate BIOS and the most modern HDD. There is some inertia that makes a lot of not-new computers over the world still useful running still useful applications that could rely on some not-modern feature. Those ones who work on software development know how stressing is write a code that has to consider several versions, some has such features and lacks of others, other versions has others features and lack other and so on. I am not able to see the problems that someone who works at HDD development sees, so I should not criticise anyone, but I agree with Don and others who thinks that the other end of the line, that end where users are, should be considered. It's not a battle between makers and users. Sure HDD and AT/A should evolve, but I modestly suggest to consider real world people needs. Regards, S�rgio Raposo - Brazil >Reasons to keep the seek command > 1. Provides backward compatibility. > a. For older BIOS's. > b. Costs nothing if you don't want to > support it. > c. Some people actually use it even if > you don't. This is an entirely new > concept to this reflector, acknowledging > that if you don't use a command, maybe > others do. I know it seems > hard to believe.... > 2. Provides diagnostic capability for the Host. > a. Verify seek times. > b. Verify mechanical soundness. > c. Yes, this can be done in spite of the > fact that the drive translates CHS, > the fact that LBA's are issued, or zones, > or other layouts make this difficult. > >Reasons why I will keep "crying" about these obsoleted commands. > 1. It is apparently only "crying" if you are part of the immoral > minority of this reflector. If you constantly harrangue two > specific companies, one of which is in Redmond, and you're > part of the moral majority of this reflector, that's ok. > 2. The T13 committee screwed up when they obsoleted these > commands. It makes it impossible for people with older systems > to replace a hard drive that goes bad. Jim McGrath only > enumerated one issue with backward compatibilty, > but he said that it was fixed. But there are many older BIOS's > that don't have this problem, So people might also have to > upgrade their BIOS. A much better option than having to > buy a completely new computer and facing a new OS and > the potential of having to upgrade a significant portion of > your software that you will now have to rent and trying to > find new drivers for your hardware. Obsoletion is a practice > that the company in Redmond has done profitably for years > 3. It doesn't matter how many years go by. If a screw-up has > occurred, it should be fixed. If companies are still putting the > command in as a NOP (per Hale), and other companies are > actually using it, isn't it kind of really still active? Doesn't it > help the user community if the command is in the STANDARD? > 4. If the committee didn't do due diligence on this, then shouldn't > they be called on it. No, I don't have the emails for earlier > than mid 96, nor do I think that it's relevant. There were people > who posted to the reflector in 2002 saying that they were using > these commands. That's what's important. Getting it > right is important. > 5. People who are the committee should be responsible for the > whole of the community. They should act for the good of the > whole. If they can't, they ought to step aside and let others > run the show. But I repeat myself. But only because I haven't > heard a valid argument yet on why the committee isn't > responsible for the whole of the community. > > > > > > > > >
