This message is from the T13 list server.
Right, and how does one test compliance to the SPEC ? Standard (OPEN SOURCED) TOOLS is the only way to keep everyone honest. Forget the "Vendor Unique" aspect. We have already seen a major cluster foxtrot in reading 48-bit v/s 28-bit reporting. What makes you think an issues as sensitive to keeping secret data or hiding true drive capacities will be deployed by all correctly? If it is broken already and everyone knows how to deal with the brokenness, leave it alone. Making everyone work twice as hard again to create work-arounds from another set of rules is silly. So if you want support for the idea, consider proposing what I retracted as "Domain Validation". If it is the spec, the "OPEN SOURCE, PUBLIC TOOL" can and will be the tool of choice to verify. So if the a vendor fails compliance they are forbidden to label, market, and/or advertise compliance to the spec. This will never happen, so why am I wasting electons. Cheer, Andre Hedrick LAD Storage Consulting Group On Wed, 12 Feb 2003, Mukesh Kataria wrote: > This message is from the T13 list server. > > > Hi Hale: > > Your consideration is well noted and accepted that instead of a > compliance tool, we should rather report problems/issues and have them > fixed via/in the spec. > > The reason to have a special tool is to tackle drives/devices which > don't seem to follow the spec correctly. In last couple of years, we > along with our OEM's have worked with 100's of different drives, of all > sizes and brands, and have faced issues with some of them. We have been > working with all drive vendors to bring these issues up and have them > fixed apprpriately on drive F/W side or BIOS/App side. > > In some cases drive firmware simply didn't comply with the spec., in > other cases, it was unclear if the drive behavior was correct or the > application expectation was correct. > > So PARTIES-2 intends to address these questions and clarify known areas > of confusion from existing spec and the tool verifies compliance of the > a drive with the HPA extension (might be a new or an old drive with > issues). > > This would give all concerned parties, drive vendors, OEMs, BIOS, > application providers etc., a common benchmark to follow. If the issues > is with the drive then drive F/W needs fixing else app/BIOS needs > fixing. > > Cheers, > Mukesh > > > -----Original Message----- > From: Hale Landis [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 12, 2003 9:49 AM > To: [EMAIL PROTECTED] > Subject: RE: [t13] Does volatile SET MAX "eliminate" HPA > > > This message is from the T13 list server. > > > On Wed, 12 Feb 2003 09:35:13 -0800, Mukesh Kataria wrote: > >This message is from the T13 list server. > >1. I do intend to propose the availability of an HPA complaince tool > >that can be used by disk drive manufacturers, OEM's etc. to validate > >the HPA compliance of a disk drive. > > Do we have a problem here? If so, lets fix the ATA/ATAPI-x description > of this feature. We don't have industry wide "compliance tests" for ATA > - why do we need one now? > > But I have a different list of issues with this HPA thing: I have > received lots of questions from people and companies attempting to use > the HPA to hide software for various legitimate purposes (asset tracking > seems to be a big one). I posted questions here on about how the HPA can > be used by these "third party" software companies (questions like if the > HPA is changed by the addtion of some > software product, does that void the computer's warrenty?") but I never > received answers to these questions. > > I look forward to any new PARTIES document and/or additional comments > from anyone about the use of the HPA. > > Hale > > > > *** Hale Landis *** www.ata-atapi.com *** > > >
