Len Brown wrote:
On Sunday 20 January 2008 07:03, Tomas Carnecky wrote:
Len Brown wrote:
I am okay with defining OSI strings for the benefit of BIOS vendors that
need to know about Linux capabilities. But the string must
identify that specific capability (or lack of a capability).
Is there a chance this will be added to future ACPI specs, or have it
standardized in one way or another? I think that would be not only good
for Linux, but all other UNIX-like operating systems as well (and maybe
Windows as well).
Not that I care, really, but for me as an outsider to the whole ACPI
domain, it seems _OSI() isn't a well thought out interface. Checking for
an OS name rather than individual capabilities may not matter as much
under Windows, but for Linux, with its rather short release cycle, it
certainly does.
Originally, there was _OS="<insert your OS name>" to identify the OS to the BIOS.
We proudly answered _OS="Linux" and broke every BIOS on Earth
that assumed that the only two choices for _OS
which corresponded to Win98 and WinNT.
That is why _OS="Microsoft Windows NT" is hardwired
into Linux and any other OS that is concerned about
following what has proven to be the only tested
path through the BIOS.
So naming the OS turned out to be a failure (for everybody,
not just for Linux -- consider that XP and Vista claim they are NT
according to _OS or they hit the same BIOS bugs we do...)
_OSI is supposed to tell the BIOS what interfaces the OS supports,
for example "Extended Address Space Descriptor".
However, it is being mis-used to identify the
version of the OS, which is why you see this:
static char *acpi_interfaces_supported[] = {
/* Operating System Vendor Strings */
"Windows 2000", /* Windows 2000 */
"Windows 2001", /* Windows XP */
"Windows 2001 SP1", /* Windows XP SP1 */
"Windows 2001 SP2", /* Windows XP SP2 */
"Windows 2001.1", /* Windows Server 2003 */
"Windows 2001.1 SP1", /* Windows Server 2003 SP1 - Added 03/2006 */
"Windows 2006", /* Windows Vista - Added 03/2006 */
ie. basically the OS name is a proxy for all the interfaces
that OS supports. Taken another way, OS-version-specific quirks
and workarounds are included in the definition of that interface...
So _OSI _is_ a good interface, it's just being misused. Thanks for the
explanation.
We could do the same with Linux, except that
1. the string "Linux" is even more poorly defined than those above,
as it has no version information.
Who came up with the idea to use "Linux"? After what you described
above, this seems even worse choice then what Windows does - they at
least have some information about the version in it.
2. the presence of the string "Linux" tends to break as many BIOS'
implementations as it fixes -- because it isn't universally tested.
So if new strings come up in the ACPI spec, we can use standard strings.
But I don't think the ACPI spec is necessary to address Linux'
problem-at-hand.
After what you explained above, I don't think either, the ACPI spec is ok.
We as the Linux community can define "Needs BIOS S3 video restore" as a string
and ship it in our kernel, telling BIOS writers about it.
However, we'd reserve the right to _stop_ answering YES to a query on that string
when we no longer need it.
Still, it would be nice to have these strings somehow standardized.
Maybe Intel and other vendors or BIOS developers come up with something
and document it properly, include some of the most important strings in
the ACPI spec? Because if Linux starts using some strings and Windows or
BSD different strings, there will surely be a mess - again.
tom
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
