On Wed, 2008-02-20 at 11:31 +0100, Tomas Carnecky wrote:

Thomas Renninger wrote:

quoted

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@vger.kernel.org/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.

quoted

Some questions and suggestions:

Is there already a replacement or will there pop up something soon,
which I may have missed?

 >

quoted

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!

quoted

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).

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html