svn commit: r216269 - head/sys/geom/part

[Bruce Evans]

On Tue, 7 Dec 2010, Bruce Cran wrote:

> On Tue, 07 Dec 2010 23:54:17 +0200
> Andriy Gapon <avg at freebsd.org> wrote:
>
>> You repeated that statement, so I am picking on you :-)
>> Can someone show me how/where exactly modern drives fakes CHS
>> geometry? Let me specifically ask that question about modern (S)ATA
>> drives directly connected to a system (controller).
>> My impression is at least since ATA-7 there is no mentioning of
>> anything CHS-related in the specification.  The fact that we keep
>> reading and interpreting some historically defined bytes that are now
>> marked as unused/reserved doesn't mean that those bytes actually mean
>> anything.
>
> You're right: I last looked at the IDENTIFY data about 7 years ago when
> those fields were defined; now they're marked as "obsolete".  I guess
> the fields are still defined to keep old tools happy. Both atacontrol
> and camcontrol are still reading the IDENTIFY data and outputting
> the CHS fields even on ATA-8 drives, which I guess they shouldn't be.

Utilities for reporting capabilities must report capabilities if they
are supported.

Whether unsupported fields should be reported as integer 0's or in a
special format (e.g., not printing anything for unsupported sub-fields)
is another question.  atacontrol is a bit too simple and inconsistent.
It prints CHS values unconditionally.  Then it prints "CFA supported"
if CFA is supported, else nothing.  Then it inconsistently prints "LBA
supported " if LBA is supported, else "LBA not supported ".  Then it
prints the number of sectors supported by LBA, but under a different
condition.  Then it prints many more things like it prints LBA, using
"supported/not supported" or, again inconsistently, "yes/no" instead of
"supported"/nothing.

Bruce