Thomas Renninger wrote:
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?
"Linux" is way too generic. The kernels is such fast moving target that
changes with every other version. The idea is to replace _OSI("Linux")
with _OSI("Needs video POST after resume") etc. To allow the BIOS to
figure out what _exactly_ it needs to do, rather then guessing based on
the kernels version etc.
A lot has been discussed in linux-acpi, though mostly hidden in related
threads. Ask Henrique, he's been trying to come up with a proper _OSI()
interface. See for example this thread:
http://www.mail-archive.com/linux-acpi@xxxxxxxxxxxxxxx/msg12262.html
The idea to remove _OSI("Linux") it to get the hardware vendors to stop
using it _now_, we don't want them to use it any longer. It will take
some time to come up with a proper interface, but at least we'll have
less legacy to deal with.
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...).
Maybe that just didn't get outside of the linux-acpi mailinglist, but
that that _OSI("Linux") is deprecated has been known for some time now.
But you are right, it was never publicly announced.
First users were asked to try acpi_osi=!Linux (sometime in the .23/.24
timeframe?)and see if it works better. Now !Linux is default, and they
are asked to try acpi_osi=Linux so that we can fill the blacklist.
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.
No, it's not sufficient, it's useless. "Linux" - what should that stand
for? How should the BIOS vendors interpret it? It's totally ambiguous.
It was removed, and should stay removed.
BIOS can do _OSI("Windows 2006") because "Windows 2006" defines a
non-moving target. MS will not change how Vista behaves without changing
the string (they sometimes update the string in service packs).
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?
BIOS should not check for a kernel version, it should check for a kernel
capability. It may be happen that you (suse) or redhat or whoever add
patches to the kernel, and then behave differently than vanilla but yet
have the same kernel version.
I asked that in another thread, if it was possible to standardize the
_OSI() strings, to that other kernels (BSD) can use it, too. Or even
have it in the ACPI standard. No answer...
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
