This message is from the T13 list server.
Pat, The implementation were all of the same with respect to the interface (i.e. same bit moves, etc..). The problem is that the command assumed an ECC implementation in the drive that no one used anymore. So the drive had to "fake" the implementation. Since the standard never gave guidance on how to fake it, what drives actually did when they implemented the command all started to drift apart. CHS address had a similar issue. Long ago the model of a fixed track size on a drive gave way to zone bit recording, which has variable sized tracks. The drives started "faking" the mapping of the LOGICAL (ATA) CHS to the PHYSICAL (actual) CHS. But the standard never got into specifying that sort of mapping - the drive vendors were free to do it any way they wanted. It turns out that lots of things that rely on implementation assumptions end up this way as the state of the art changes. Or if they don't then eventually they die out, since something else that does adapt to new technology takes its place. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 10:08 AM To: [EMAIL PROTECTED] Subject: RE: [t13] vendor-specific as good as optional, outside the o.s.? This message is from the T13 list server. >>> Hale Landis 03/21/02 10:34AM >>> > The problem with R/W LONG ... > There was (is) no single implementation. > As long ago as 1990 > there were widely different implementations of R/W LONG. Ahh. Here we see industry again flatly disregarding the published standard? On paper, Ansi said one thing clearly. In reality, the industry did something entirely different, even in so-called "compliant" drives? Thus T13 gains credibility, by removing from the formally standardised features, any features that the commodity desktop O.S.' do not commonly exercise? x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> [EMAIL PROTECTED] 03/21/02 10:18AM >>> > R/W Long and you will probably continue to support > that for quite a while > (even with the drive larger than 28bit?). This is not possible. To "continue to support" seek & r/w long beyond 28 bit Lba's in Ata and beyond 32 bit Lba's in Scsi has no agreed meaning. Beyond those barriers, no device folk can choose to "continue to support" seek & r/w long, not unless someone on the committee makes a proposal to carry these commands forward. > And for the above 28 bit area, ... > you might implement vendor specific commands > to "address" that Yes. > (which will keep the R/W Long > still formally in "obsolete" state)? Not obsolete. NEVER DEFINED. Never Defined is different than Obsolete: with Never Defined, the drive customer and the drive supplier lose their common point of reference. They can't begin to work to cooperate with each other until after they meet. >>> Hale Landis 03/21/02 10:34AM >>> > R/W LONG ... the commands > became first "vendor specific" > and then "obsolete". That process required several years. Help? Did you mean to say first optional and then obsolete? Never vendor-specific, unless we look back to before the ops were first standardised? >>> Hale Landis 03/21/02 09:27AM >>> > Nothing quiet about how T10 and T13 operate. Sorry I was unclear. When I say T10 & T13 are killing off seek & r/w long by "quiet neglect" I mean to say that the published standards do not emphasise that the obsolete/ optional/ mandatory seek, r/w long, etc. stop short at the 28/32 bit barriers. Personally I think it's reasonable for an ignorant reader to expect that all commands that address any Lba's can address all Lba's, unless that reader is explicitly told differently. But the published standards violate this (and many other) reasonable expectations (e.g. often "may" is used as an abbreviation for "might or might not").
