Hi,
please correct me if I am wrong or missed something:
osi=linux was an ability for vendors to provide Linux specific BIOS
updates/quirks.
_OSI("Linux") returned true until kernel version 2.6.23 (included?).
This has been replaced by rather huge black+white lists (at least they
most probably will grow huge) to get rid of it again.
Goal is to not return _OSI("Linux") as Intel identified it (after
inventing it? Doesn't really matter...) as "not the right thing to do"
as it does not consider fixes that might show up in specific kernel
versions in the future. This is the only reason I found, did I miss one
or the other?
Some questions and suggestions:
Is there already a replacement or will there pop up something soon,
which I may have missed?
This is an interface to the outside world (out of the kernel... in this
case not to userspace via /proc /sys ioctl, but to the BIOS).
Such interfaces should have a very long lifetime, once they are
implemented. In this case it should have an even much longer life time
than any /sys or whatever userspace interface. Telling vendors that this
will vanish and giving them time to remove it from their BIOSes or
better replace it with something else is the way to go here IMO.
The current policy is to just return zero on _OSI("Linux").
I don't get it why you do this.
You break machines on purpose.
Machines were vendors possibly have invested time to improve them for
Linux.
Why don't you just announce it, write it down in Documentation, also
write it to dmesg, instead of "pls send acpidump to acpi list",
something like: "osi=linux is deprecated and will get removed" (ok there
popped up a way too much of these, but maybe dmiblacklist the message,
don't do any functional change for now...).
Why shouldn't I remove the whole dmi black/white listing from our
OpenSUSE kernel and return true for _OSI("Linux"), this probably fixes a
lot machines and avoids bug reports (and annoyed users). I plan to do
this rather soon if I don't get some good arguments.
IMO this should also be done mainline. It is a pity that 2.6.24 now has
this. IMO this should even go back to a 2.6.24.X stable kernel.
Just let it in and announce to not use it and provide something else
(this has time then...).
-------------------
Here a suggestion for an enhanced Linux Operation System Identification
interface for ACPI:
For general BIOS hot-fixes a check for osi=linux is sufficient for
vendors and allows them to provide a fix without risking breakage of
their Windows OS. This one should stay.
The problem is you do not know in what kernel version this might get
fixed at the time the BIOS is published with the "short term
workaround". While this knob is essential for vendors for pre-loads, it
might break the machine if the user is trying to install a newer Linux
distribution with a newer Kernel where the problem got fixed. Then the
workaround might even slow down or break the system...
An example:
Lenovo wants to get rid of brightness switching via their old method
(int10?). But this needs in-kernel graphics driver support for Intel
graphics cards. Therefore ibm_acpi currently simulates this, the
specified ACPI brightness interface cannot be used. In which kernel
version in-kernel graphics drivers will be supported and Lenovo can
safely throw out int10 brightness switching from their BIOSes is not
known yet.
I think an appropriate interface could look like this:
Give vendors the possibility of an "infinite" tag, like osi=linux
Combine this somehow with a kernel version interface.
Vendors later should be able to simply switch from infinite to
kernel_version < xy by just modifying a simple line.
=========================================
AML example (when it's not yet known in which kernel version the fix
will be):
/* This will get filled with kernel the version */
Name (KERN, Package (0x3)
{
0, 0, 0
})
If (CondRefOf (_OSI, Local0))
{
/* Are we running on linux? */
If (_OSI ("Linux"))
{
Store (1, QURK)
}
}
=========================================
AML example (when it *is* known in which kernel version the fix will be,
say 2.6.27):
/* This will get filled with kernel the version */
Name (KERN, Package (0x3)
{
0, 0, 0
})
If (CondRefOf (_OSI, Local0))
{
/* Are we running on linux? */
If (_OSI ("Linux"))
{
/* Does linux already support kernel version query? */
If (CondRefOf (_LKV, Local0))
{
/* LKV (Linux Kernel Version) returns a package with 3 int
values */
Store(_LKV, KERN)
/* Only activate quirk if this is a 2.6
kernel with version less than 27 */
If And(And(And((LEqual(Index(1, KERN), 2)),
(LEqual(Index(2, KERN), 6)),
(LLess(Index(3, KERN), 27))))
{
Store (1, QURK)
}
}
}
So the new thing here is:
Method(_LKV, 0, ..)
that needs to be implemented by the kernel and returns the kernel
version in a Package with three elements.
Does this make sense?
Is it too complicated?
Better ideas?
Thomas
-
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
