https://bugzilla.novell.com/show_bug.cgi?id=299267#c21
--- Comment #21 from Tejun Heo 2007-08-29 05:51:10 MST ---
It's a policy decision and both directions have pros and cons. In the long
term, I think we should move away from unlocking HPA area by default. It isn't
necessary for normal operation anymore and the spec specifically states that
HPA is reserved for BIOS (firmware) and not to be meddled with by OS. As I
wrote before, some ACPI implementation might depend on it too.
But you're also right that maintaining compatibility with older distributions
is very important. I think the best we can do here is implementing auto
fallback mechanism so that we can move forward while maintaining backward
compatibility where necessary. I can implement SET_MAX snoop in the driver
such that userland can unlock HPA without worrying about device detach and
rescan.
1. check partition table, if it extends beyond the current limit and unlocking
HPA will make the partition table valid, issue SET_MAX
2. libata snoops SET_MAX and on completion resizes the device accordingly.
3. userland continues.
Basically, there will be an executable which unlocks HPA iff the existing
partition table requires it. It can probably be called from udev after each
libata device detection. This will work for both during and after installation
and drives with mixed HPA locked/unlocked status should work fine too.
How does it sound?
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.