Re: libata: implement on-demand HPA unlocking

[Phillip Susi <psusi@cfl.rr.com>]

On 2/9/2011 4:13 PM, Alan Cox wrote:
> Correct. The vendors however primarily used it for completely different
> things. Also trusting the BIOS is generally not a good idea.

I disagree.  Trusting the bios /generally/ is exactly what you should
do.  When it is known to be broken in specific cases, then sure, over
ride it, but /generally/ you should assume it knows what it's talking about.

>> ubuntu forums and bug tracker each year of people with HPA problems and
>> it always seems to be a small area, as opposed to hiding everything
>> above 128 MB or something.
> 
> Possibly because we unlock them in the distro cases.

I meant that the reports I have seen show the kernel prints listing the
size before and after the unlock, and they are always very close.

> So the best option from a kernel point of view appears to be to unlock
> the drive but to remember and enable user space to retrieve the
> parameters.
> 
> In essence "what geometry do I care about" is policy for application code
> like dmraid, and it can be better refined there. However we can't refine
> it there if we don't unlock.

That assumes that the bios is reserving the HPA for no good reason at
all and it is safe to ignore it.  This does not seem to be a good
assumption based on both the ATA spec and the behavior of Windows.  At
any rate, the decision to NOT unlock by default seems to have been made
years ago when libata was written, and certain distributions decided to
risk breaking compatibility with hardware that runs Windows just fine in
favor of not breaking upgrades from systems installed with the old ide
driver that did default to unlocking.

The discussion at hand is about a change made a few months ago that is a
good compromise between always unlocking, and never unlocking.  Both of
those have problems, so a good compromise can have the benefits of both,
and the drawbacks of neither.  Furthermore, it is already in the kernel,
so continuing to argue about whether it should have been done or not
seems a moot point.