On Wed, 2008-02-20 at 11:31 +0100, Tomas Carnecky wrote:
> 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.
Ok, I see the point and I agree that kernel versions only is a bit
problematic. I still like it, because it seem to me the only way that is
a bit generic.
So the suggestion is to introduce very specific strings (hopefully not
much) for specific milestones/patches similar to "Windows 2006 SP1" we
might have a "in-kernel graphics", but this hopefully will be the only
one... The string(s) are listed on acpi.sourceforge.com? Hmm, not sure
whether this is such a perfect idea or could work at all, maybe for very
extrem/huge changes.
But that is not enough. There is nothing wrong with giving the vendors
the possibility to check whether they are running on Linux.
Document the problem of future kernel versions for vendors.
I expect most of the if(linux) AML fixups from vendors make very much
sense to keep them forever.
For all the stuff like: Windows likes to have it this way, it violates
all kinds of specifications for it, so for Linux we do it right and
provide a proper interface.
There are dozens of more arguments..
> 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.
It is not working like that!
You cannot provide an important interface.
Then realize that it is not exactly what it was intended for and just
rip it out.
While modifying sysfs and procfs without announcing must not happen, it
is by far not that bad.
Just keep it, tell the vendors that they should not use it, put in ugly
messages if they do (if you like black/white list the message...). If
this really should vanish, what is IMO a really bad idea.
But do not just remove it!
> > 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?
That the Operating System is a Linux kernel?
> It's totally ambiguous.
I do not understand what is so ambiguous about that.
All more specific solutions should get embedded into this anyway, e.g.:
if (linux) {
if(in-kernel_graphics)
...
if(latest-hack)
...
}
> It was removed, and should stay removed.
I don't know whether it stays removed, I hope not.
I hope Len is realizing that all the work done the last weeks wasn't
really worth it and that there might come a lot more work. If you
already start black/white listing machines after some weeks, then there
are more out there. Currently unnecessarily broken. BTW, what should be
the final solution? You tell the vendor that he should remove the linux
quirk from their BIOSes for the future, best with the next BIOS update
and then you are going to fix it? (not sure whether fix it is the right
word, better hack/work around it) to make it work somehow?
Better stop wasting time on fixing things that have already been fixed
for Linux.
Also a lot users had to debug some BIOS issues to the root because the
policy was to not provide workaround boot parameters, sysfs interfaces
(e.g. thermal trip points) or other workarounds. There were discussions,
some disagreements, but in the end it made some sense.
I won't let OpenSUSE users run into such problems because of this one,
it just makes no sense.
There still were not much more arguments than "It's not the way to go",
there is no suggestion for an alternative also...
> 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.
Yes this is indeed a problem for specific issues.
It would be sufficient for e.g. ACPI interpreter problems for which you
know that they are so intrusive, that they will never be backported into
a half-way stable kernel.
>
> 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...
What are your ideas?
It's not included in the link you added.
Thanks,
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
