Re: libata: implement on-demand HPA unlocking

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> What experience?  The only reason that I have heard for unlocking it is 

About ten years of distributions, drive hiding magic for old BIOSes and
other pain.

> to maintain compatibility with the old ide driver which did so.  What 
> reason does Linux have to access an area of the disk that the system has 
> made clear it should not?

It's unfortunate you won't listen but continue to spout stuff from a
standard no vendor, no OS and no product ever followed. ATA is not built
on strict adherance to formal standards, nor is the PC.

> What part to you disagree with?  That the compromise in place can have 
> the benefits of both, but the drawbacks of neither?

That there is any point doing anything but always unlocking.

> I understand that dmraid could work around the problem, but there should 
> not be a problem in the first place.  The system has asked that we not 
> touch that part of the disk

I see no point continuing this discussion if all you want to do is wave a
'standard' that isn't followed by anyone and breaks stuff and demand we
follow it. Always unlock in the kernel, make both sets of geometry
available via sysfs and then fix dmraid. It's an easy problem to solve
and because dmraid knows a lot about fakeraid stuff it also knows enough
to peer in various locations and figure out which to use - something that
the kernel quite intentionally does not.

Alan