Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Thomas Renninger]

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

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Tomas Carnecky]

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

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

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Henrique de Moraes Holschuh]

On Wed, 20 Feb 2008, Tomas Carnecky wrote:
> 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:

No, I haven't.  Len is the mastermind behind it, AFAIK.  I am just one of
the interested parties.  I have been burned by halfway-done jobs in the
kernel once-too-many already IMO, so I am sticking around the threads to
make sure THIS time, at least I will also be at fault if it is done wrong.

The fact that Lenovo (and therefore, ThinkPads) is one of the vendors
directly affected by OSI(Linux) issues, has a LOT to do with my continued
participation on this issue, too.  The saner the ThinkPad firmware is, from
a Linux standpoint, the better for me.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Thomas Renninger]

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

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Matthew Garrett]

Let's look at this differently. Most hardware is produced by vendors who 
don't care about Linux. We need to make that hardware work anyway. The 
only way we can achieve that is to be bug-compatible with Windows. 
Therefore, any way in which Linux behaviour varies from Windows 
behaviour is a bug. The only reason to export any indication that the 
kernel is Linux is because our behaviour is not identical to Windows. 
But, given that that's a bug, the solution should be to fix Linux and 
not to encourage vendors to put workarounds in their firmware.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Thomas Renninger]

On Wed, 2008-02-20 at 17:32 +0000, Matthew Garrett wrote:
> Let's look at this differently. Most hardware is produced by vendors who 
> don't care about Linux. We need to make that hardware work anyway.
Not really. If you buy machine noname XY, you have to face the fact that
HW may not work on Linux correctly. You can try fix to it, but you
cannot write a driver for WLAN card from vendor noname and card reader
from "never heard of that company". If you buy the wrong graphics card
you may end up without 3D and whatever else cool features the card
supports.

So at least since HP, Dell, Lenovo (also Acer?) are selling pre-loaded
Linux laptops, you should be smart enough to take such a thing where the
BIOS is adjusted to run on Linux or you pretty much have to reckon with
trouble.

So being Windows compatible is nice, but sticking to specifications is
more important (we are far away from and never will be Windows
compatibility in WMI implementation right?). Imagine a vendor using
if(linux) provides as a whole SSDT with all the fan and thermal
implementations perfectly fit to the ACPI specification and therefore
stick to the Linux kernel implementations?

Next point is that if vendors pre-load their model with a specific
distribution, they need such a knob.
Please do not think about what happens when I upgrade to the latest
kernel (which should still be no problem when they know how to use
this). Think about how these vendors should fix a complex Linux bug via
a BIOS hot-fix update ...

Think about a functional change they have to implement in their BIOS for
a Windows Vista SPX change. While the machine may still run fine with
the latest mainline kernel, the kernel they have to provide support for
will break. I see the problem with this scenario, but try to think from
Dell's/HP's/... point of view. They want to have such a thing.

>  The 
> only way we can achieve that is to be bug-compatible with Windows. 
> Therefore, any way in which Linux behaviour varies from Windows 
> behaviour is a bug. The only reason to export any indication that the 
> kernel is Linux is because our behaviour is not identical to Windows. 
Linux behaviour is not identical to Windows, never will be and after
vendors start pre-loading also do not need to be...
> But, given that that's a bug, the solution should be to fix Linux and 
> not to encourage vendors to put workarounds in their firmware.
I see it the other way round. Encourage vendors to fix their BIOSes,
instead of putting "Windows compatibility" workarounds into the kernel.

   Thomas

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Henrique de Moraes Holschuh]

On Wed, 20 Feb 2008, Matthew Garrett wrote:
> Let's look at this differently. Most hardware is produced by vendors who 
> don't care about Linux. We need to make that hardware work anyway. The 
> only way we can achieve that is to be bug-compatible with Windows. 
> Therefore, any way in which Linux behaviour varies from Windows 
> behaviour is a bug. The only reason to export any indication that the 
> kernel is Linux is because our behaviour is not identical to Windows. 
> But, given that that's a bug, the solution should be to fix Linux and 
> not to encourage vendors to put workarounds in their firmware.

That punishes vendors which actually care about Linux.  These are quite
rare in the laptop and desktop market, but they do exist.

And such vendors are quite *common* in the enterprise hardware market which
doesn't run Windows.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Matthew Garrett]

On Wed, Feb 20, 2008 at 07:21:57PM +0100, Thomas Renninger wrote:
> On Wed, 2008-02-20 at 17:32 +0000, Matthew Garrett wrote:
> > Let's look at this differently. Most hardware is produced by vendors who 
> > don't care about Linux. We need to make that hardware work anyway.
> Not really. If you buy machine noname XY, you have to face the fact that
> HW may not work on Linux correctly. 

No. You have failed. Do not pass go.

> You can try fix to it, but you
> cannot write a driver for WLAN card from vendor noname and card reader
> from "never heard of that company". If you buy the wrong graphics card
> you may end up without 3D and whatever else cool features the card
> supports.

That's fine. Some hardware support is difficult. Some hardware support 
is not difficult. The only possible situation in which exporting some 
sort of OSI value for Linux is helpful is when the firmware authors know 
what the difference between the Linux and Windows behaviours are. If we 
know that, we can fix it. Fixing it not only fixes the machine in 
question, it probably fixes a large number of other machines. This is a 
preferable solution.

> So at least since HP, Dell, Lenovo (also Acer?) are selling pre-loaded
> Linux laptops, you should be smart enough to take such a thing where the
> BIOS is adjusted to run on Linux or you pretty much have to reckon with
> trouble.

Argh. No. If the BIOS is adjusted to run on Linux, it indicates that 
we've failed. Completely. Utterly.

> So being Windows compatible is nice, but sticking to specifications is
> more important (we are far away from and never will be Windows
> compatibility in WMI implementation right?).

No! What's the point in sticking to specifications when there's only one 
implementation? Windows is the de-facto specification for ACPI, and we 
should follow it.

> Next point is that if vendors pre-load their model with a specific
> distribution, they need such a knob.

Fixing Linux is easier than fixing firmware in almost every single case. 
If vendors are installing Linux without working with the distribution 
vendor, then that's unfortunate and they're likely to have problems. I'm 
not going to prioritise them above the huge number of users buying 
hardware from vendors who aren't as foolish.

> Please do not think about what happens when I upgrade to the latest
> kernel (which should still be no problem when they know how to use
> this). Think about how these vendors should fix a complex Linux bug via
> a BIOS hot-fix update ...

They shouldn't. They should push out a software update.

> >  The 
> > only way we can achieve that is to be bug-compatible with Windows. 
> > Therefore, any way in which Linux behaviour varies from Windows 
> > behaviour is a bug. The only reason to export any indication that the 
> > kernel is Linux is because our behaviour is not identical to Windows. 
> Linux behaviour is not identical to Windows, never will be and after
> vendors start pre-loading also do not need to be...

Wrong.

> > But, given that that's a bug, the solution should be to fix Linux and 
> > not to encourage vendors to put workarounds in their firmware.
> I see it the other way round. Encourage vendors to fix their BIOSes,
> instead of putting "Windows compatibility" workarounds into the kernel.

By which you mean "Cater for a small market, rather than the large one"? 
No. That would be ridiculous. Our compatibility is sufficiently good 
that I'm not going to recommend users buy one of the tiny number of 
laptops available with a "supported" Linux install over buying a laptop 
that actually fits their needs.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Matthew Garrett]

On Wed, Feb 20, 2008 at 03:23:40PM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 20 Feb 2008, Matthew Garrett wrote:
> > Let's look at this differently. Most hardware is produced by vendors who 
> > don't care about Linux. We need to make that hardware work anyway. The 
> > only way we can achieve that is to be bug-compatible with Windows. 
> > Therefore, any way in which Linux behaviour varies from Windows 
> > behaviour is a bug. The only reason to export any indication that the 
> > kernel is Linux is because our behaviour is not identical to Windows. 
> > But, given that that's a bug, the solution should be to fix Linux and 
> > not to encourage vendors to put workarounds in their firmware.
> 
> That punishes vendors which actually care about Linux.  These are quite
> rare in the laptop and desktop market, but they do exist.

It doesn't punish them. They're the ones who are going to work with us 
to ensure that Linux works on their hardware, and their needs are going 
to be prioritised over those of vendors who don't care about Linux. The 
other choice (encourage vendors to put workarounds in their firmware 
instead) *does* punish users who've ended up with laptops that aren't 
actively supported - like, say, pretty much anything on the market.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Henrique de Moraes Holschuh]

On Wed, 20 Feb 2008, Matthew Garrett wrote:
> It doesn't punish them. They're the ones who are going to work with us 
> to ensure that Linux works on their hardware, and their needs are going 

And since when we have to work exactly like Windows (whatever version) does
in THAT case?

Also, why would one thing (proper replacement for OSI(Linux)) cause any sort
of difference over the other (trying to be bug-to-bug compatible with
Microsoft crap).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Sergio Monteiro Basto]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]


On Thu, 2008-02-21 at 00:13 -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 20 Feb 2008, Matthew Garrett wrote:
> > It doesn't punish them. They're the ones who are going to work with us 
> > to ensure that Linux works on their hardware, and their needs are going 
> 
> And since when we have to work exactly like Windows (whatever version) does
> in THAT case?
> 
> Also, why would one thing (proper replacement for OSI(Linux)) cause any sort
> of difference over the other (trying to be bug-to-bug compatible with
> Microsoft crap).
> 

I agree with Henrique. Since we have, in fact, more Windows cases than
Linux cases and for Linux, just announce that  is recommended,
osi=linux. 
Also it is possible put Linuxs bios in a kind of white-list in kernel
code ...

-- 
Sérgio M. B.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2192 bytes --]

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Len Brown]

Thomas,
Thanks for the note.
Please read the messages on linux-acpi with "dmi" in the subject
for some background.

yes, OSI(Linux) was enabled by default through 2.6.22
and was disabled by default starting in 2.6.23.

The reason it has come up recently is because
it got into a reference BIOS -- and I'm sorry
to admit that I was a party to that -- I
wasn't thinking.

Tomas Carnecky's reply is 100% correct.
We can't support OSI(Linux) any more than we
could support _OS="Linux", or Microsoft
could support OSI(Windows) -- particularly
on an OS that changes as fast as Linux does.
To do so would in some cases put Linux at
a permanent disadvantage to competing operating systems.

Yes, we are attempting to close Pandora's box.
I think we'll be successful, though we have to handle the
Dell and Lenovo systems which actually use OSI(Linux)
on purpose. Everybody else appears to be using it
by mistake, sometimes with no effect,
sometimes with negative effect.

No, the DMI list is not large,
it is mostly comments and it is __init.

I _strongly_ urge you to not fork from
the .stable and mainline kernel in this area.

OEMs that really want to modify the BIOS to recognize
OS interfaces that are in Linux should propose
new OSI strings that specify interfaces, not broad
categories of operating sytems; and in Linux we
shoudl use, or not use, those strings, as appropriate.
I've recently been in discussion with OEMs on exactly
this topic -- I'm sorry it didn't happen a year ago.

thanks,
-Len

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Matthew Garrett]

On Thu, Feb 21, 2008 at 12:13:24AM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 20 Feb 2008, Matthew Garrett wrote:
> > It doesn't punish them. They're the ones who are going to work with us 
> > to ensure that Linux works on their hardware, and their needs are going 
> 
> And since when we have to work exactly like Windows (whatever version) does
> in THAT case?
> 
> Also, why would one thing (proper replacement for OSI(Linux)) cause any sort
> of difference over the other (trying to be bug-to-bug compatible with
> Microsoft crap).

Offering OSI(Linux) makes a statement about our implementation - we're 
telling the firmware that it behaves in a certain way. That lets vendors 
start depending on that behaviour, and if that behaviour turns out to be 
different to Windows then we never get to fix that behaviour. Fine for 
vendors that have special-cased their firmware, bad for the vast 
majority of systems.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Theodore Tso]

On Thu, Feb 21, 2008 at 09:15:32AM +0000, Matthew Garrett wrote:
> 
> Offering OSI(Linux) makes a statement about our implementation - we're 
> telling the firmware that it behaves in a certain way. That lets vendors 
> start depending on that behaviour, and if that behaviour turns out to be 
> different to Windows then we never get to fix that behaviour. Fine for 
> vendors that have special-cased their firmware, bad for the vast 
> majority of systems.

Exactly, that's the problem.  Suppose we put in an OSI(Linux), and
Lenovo, thanks to the fact that they are working with Novell, puts in
a special case hack just for whatever version of SLES they happen to
be testing with.  Well, great.  Now suppose that three other laptops
from different manufacturers (say, Sony, Fujitsu, and Asus) do things
differently, the Windows way, and someone posts a patch to the ACPI
drivers (and it might not and probably won't be the Thinkpad specific
thinkpad_acpi.c file) which changes things so that it works for Sony,
Fujitsu, et. al. --- and in the process, it breaks things for Lenovo,
because the Lenovo is doing something special based on OSI(Linux)
thanks to their special collaboration with Thomas Renniger and Novell.
Oops.  Now we have a mess, and we have to start having special
DMI-based blacklists and whitelists, and life generally sucks.

It would be much better if we define feature-specific OSI() strings
that have well defined meanings for each place where Lenovo has to do
something different than What Happens With Windows --- especially for
stuff which is generic, since all laptop manufactuers need to
interoperate with whatever cr*p Windows ship.  At the end of the day,
since Intel was originally too lazy to ship an ACPI conformance test
suite, like it or not, Windows *has* become the APCI conformance test
suite, and all laptop manufacturers (at least for today) must bow to
the might and power which is the market share of Microsoft.

						- Ted

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Matthew Garrett]

On Thu, Feb 21, 2008 at 08:51:32AM -0500, Theodore Tso wrote:

> It would be much better if we define feature-specific OSI() strings
> that have well defined meanings for each place where Lenovo has to do
> something different than What Happens With Windows --- especially for
> stuff which is generic, since all laptop manufactuers need to
> interoperate with whatever cr*p Windows ship.  At the end of the day,
> since Intel was originally too lazy to ship an ACPI conformance test
> suite, like it or not, Windows *has* become the APCI conformance test
> suite, and all laptop manufacturers (at least for today) must bow to
> the might and power which is the market share of Microsoft.

My concern with this is that until we know where we deviate from the 
Windows behaviour, we don't know what strings we'd need to provide. And 
once we *do* know where we deviate, we should fix that deviation rather 
than provide an identifying string.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Alexey Starikovskiy]

Matthew Garrett wrote:
> On Thu, Feb 21, 2008 at 08:51:32AM -0500, Theodore Tso wrote:
>
>   
>> It would be much better if we define feature-specific OSI() strings
>> that have well defined meanings for each place where Lenovo has to do
>> something different than What Happens With Windows --- especially for
>> stuff which is generic, since all laptop manufactuers need to
>> interoperate with whatever cr*p Windows ship.  At the end of the day,
>> since Intel was originally too lazy to ship an ACPI conformance test
>> suite, like it or not, Windows *has* become the APCI conformance test
>> suite, and all laptop manufacturers (at least for today) must bow to
>> the might and power which is the market share of Microsoft.
>>     
>
> My concern with this is that until we know where we deviate from the 
> Windows behaviour, we don't know what strings we'd need to provide. And 
> once we *do* know where we deviate, we should fix that deviation rather 
> than provide an identifying string.
>
>   
How about WMI?
Do you think that there will be some point in the future,
 when we could claim that our WMI implementation is the
same as Windows + HW manufacturer private driver?

Regards,
Alex.

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Matthew Garrett]

On Thu, Feb 21, 2008 at 05:48:33PM +0300, Alexey Starikovskiy wrote:

> How about WMI?
> Do you think that there will be some point in the future,
> when we could claim that our WMI implementation is the
> same as Windows + HW manufacturer private driver?

When vendors require custom drivers, we're going to end up requiring a 
custom driver. That's true regardless of how the functionality is 
exposed. The solution there is to encourage vendors not to require 
custom drivers, not to get them to expose the same functionality in two 
different ways.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Alexey Starikovskiy]

Matthew Garrett wrote:
> On Thu, Feb 21, 2008 at 05:48:33PM +0300, Alexey Starikovskiy wrote:
>
>   
>> How about WMI?
>> Do you think that there will be some point in the future,
>> when we could claim that our WMI implementation is the
>> same as Windows + HW manufacturer private driver?
>>     
>
> When vendors require custom drivers, we're going to end up requiring a 
> custom driver. That's true regardless of how the functionality is 
> exposed. The solution there is to encourage vendors not to require 
> custom drivers, not to get them to expose the same functionality in two 
> different ways.
>
>   
It will always be two ways -- Windows way with WMI and other OSes way 
without it.
The choice is there to place this non-Windows custom driver -- in C or 
in AML.
This is their choice, right? If they choose to not create custom
driver or have some concerns about complexity of its implementation in
C rather than in AML, they should be allowed to choose AML.

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Thomas Renninger]

On Thursday 21 February 2008 09:41:13 you wrote:
> Thomas,
> Thanks for the note.
> Please read the messages on linux-acpi with "dmi" in the subject
> for some background.
Can you be a bit more specific. Grepping for "dmi" is a bit verbose on the 
linux-acpi list.

> yes, OSI(Linux) was enabled by default through 2.6.22
> and was disabled by default starting in 2.6.23.
>
> The reason it has come up recently is because
> it got into a reference BIOS -- and I'm sorry
> to admit that I was a party to that -- I
> wasn't thinking.
>
> Tomas Carnecky's reply is 100% correct.
> We can't support OSI(Linux) any more than we
> could support _OS="Linux", or Microsoft
> could support OSI(Windows) -- particularly
> on an OS that changes as fast as Linux does.
> To do so would in some cases put Linux at
> a permanent disadvantage to competing operating systems.
No, not providing an interface at all is a disadvantage, a permanent one.

You all look at this too much from the kernel point of view:
You are a vendor and you want to provide a BIOS update, because on the model 
you sold with Linux on it, there is a bug. For some reason Linux is not 100% 
compatible to Windows and the bug does only exist on Linux.
But you still have to support Windows on that machine and unfortunately this 
machine got sold with Windows 10x more often than with Linux.
The bug is rather complicated to fix/workaround through the OS (E.g. suspend 
reordering, AML bug, you simply misread the ACPI spec and it did work for 
Windows (the ACPI kernel maintainer likes to add the "compatibility" hack, 
but it's just too intrusive to backport into your stable kernel release you 
support), ...). But a modification in the DSDT is a one-liner and an obvious 
fix.
You desperately search for a flag to be able to make sure you do not risk to 
break Windows...
Now they have to ignore the bug. Bad for the vendor, bad for the customer, bad 
for us (yet another complex "Windows compatibility" hack).

> Yes, we are attempting to close Pandora's box.
Too late and IMO there is nothing bad about it.
> I think we'll be successful, though we have to handle the
> Dell and Lenovo systems which actually use OSI(Linux)
> on purpose.
> Everybody else appears to be using it 
> by mistake, sometimes with no effect,
> sometimes with negative effect.
Are you sure, they use it by mistake?
Again, think from a vendor's point of view...
What I expect happened here:
Vendors thought about better Linux support. Some already chose a distribution 
which (most common should be Ubuntu here, It's Dell, already Acer? and 
others?) They pre-load it with a specific, probably a rather stable release 
and sell their laptops with it. And they have to provide support for it, at 
least for the release they sold it with.

I expect the first thing they did when thinking about Linux support is that 
they added something similar like:
Name (Linx, 0)
...
if (_OSI("Linux"))
   Store(1, Linx)

to their BIOSes, the same they do for Windows'es they have to support.
They even may have verified it working... the "NOP".
Now if there pop up problems, they can and will use this to provide Linux 
specific BIOS fixes with code that is only processed on Linux, because they 
cannot risk to break Windows.

If you rip this out now you will see:
  - white/black listed NOPs that break after a BIOS update with later
    kernels
  - No BIOS updates for Linux at all in this area (and this is what I mean
    with permanent disadvantage)


> No, the DMI list is not large,
It is very confusing.
> it is mostly comments and it is __init.
That is not really important.
>
> I _strongly_ urge you to not fork from
> the .stable and mainline kernel in this area.
Matthew's arguments are quite interesting.
I still disagree with:
  - simply ripping it out (at least do it soft)
  - Remove all possibilities for vendors who want support Linux
    to provide safe, only Linux affecting BIOS updates, just for
    the sake of "being Windows compatible"

The strongest argument: I agree that they of course should contribute their 
code and start working on the kernel, provide software updates etc.
But those guys do not have to share much, anyway:
(Some guessing now): Asus, Acer, Lenovo, Dell,...: have to make sure that they 
buy and put hardware into their machines from companies that work on Linux 
now. This is where we will see most advantages. They do not manufacture most 
HW components themselves (network/wlan/sound/... cards). They manufacture or 
at least have direct control over their BIOS, though. So this kind of hot-fix 
is most convenient for them (or may be the only possibility for them).

> OEMs that really want to modify the BIOS to recognize
> OS interfaces that are in Linux should propose
> new OSI strings that specify interfaces, not broad
> categories of operating sytems; and in Linux we
> shoudl use, or not use, those strings, as appropriate.
> I've recently been in discussion with OEMs on exactly
> this topic -- I'm sorry it didn't happen a year ago.
So you mean "SLED 10 SP2", "UBUNTU supported version XY" strings?
While this would be helpful for vendors on shortterm, they would realize soon, 
that their customers get angry after updating to an unsupported, brand-new 
kernel/distribution. This is exactly what we do not want to have (and what 
could happen soon).

IMO osi=linux should stay (must stay now!).
Your concerns that the vendors are messing up their BIOSes, so that this has 
to be workarounded in later kernels etc. is utopistic.
Vendors who are using such flags in their BIOSes want their machines to run 
fine on Linux forever. They do not add ugly stuff in there on purpose. 
Explain them how to use it. They should stick to the specifications, ask on 
acpi list if in doubt. We should make up a documentation: "Guide for Linux 
ACPI BIOS updates", ...

The whole problem here is that those guys who are affected have never been 
asked...
Shouldn't there be some Dell activity on some Linux/Ubuntu lists now? I bet 
every vendor will tell you that he wants to have such a thing. Find out some 
people who are in charge for Linux and invite them for a discussion.
A general Linux flag is the way to start, everything more specific will/can 
get embedded into this flag later if it makes sense (without any risk for the 
vendors to break Windows). There are (I expect most) cases where embedding 
stuff into if(linux) makes a lot sense. But Henrique and others are probably 
right that we need something more fine grained later (in rare cases, e.g. the 
in-kernel graphics driver issues).

   Thomas

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Henrique de Moraes Holschuh]

On Thu, 21 Feb 2008, Matthew Garrett wrote:
> My concern with this is that until we know where we deviate from the 
> Windows behaviour, we don't know what strings we'd need to provide. And 
> once we *do* know where we deviate, we should fix that deviation rather 
> than provide an identifying string.

IMO we should "fix" deviations *only* when it makes sense to do so (I bet at
least one of the deviations we are going to find will be so hideously wrong
and ugly when compared to the Right Thing, that we will be at a very
unconfortable position if we need to implement it).

We better reserve judgment of what deviations we should be fixing or not for
when we find them in the first place.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Henrique de Moraes Holschuh]

On Thu, 21 Feb 2008, Sergio Monteiro Basto wrote:
> On Thu, 2008-02-21 at 00:13 -0300, Henrique de Moraes Holschuh wrote:
> > On Wed, 20 Feb 2008, Matthew Garrett wrote:
> > > It doesn't punish them. They're the ones who are going to work with us 
> > > to ensure that Linux works on their hardware, and their needs are going 
> > 
> > And since when we have to work exactly like Windows (whatever version) does
> > in THAT case?
> > 
> > Also, why would one thing (proper replacement for OSI(Linux)) cause any sort
> > of difference over the other (trying to be bug-to-bug compatible with
> > Microsoft crap).
> > 
> 
> I agree with Henrique. Since we have, in fact, more Windows cases than
> Linux cases and for Linux, just announce that  is recommended,
> osi=linux. 

EH? I am *against* osi=Linux.  I am for a proper *replacement* for
OSI=Linux, *and* trying to be Windows-compatible where possible.

> Also it is possible put Linuxs bios in a kind of white-list in kernel
> code ...

Linux-BIOS boxes *really* should not need ACPI for anything other than the
very basic stuff, at all.  Nor should them implement SMM handling, or any
other such crap that always bite us back in the nether regions, with
poisoined teeth.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Matthew Garrett]

On Thu, Feb 21, 2008 at 04:41:21PM +0100, Thomas Renninger wrote:

> The bug is rather complicated to fix/workaround through the OS (E.g. suspend 
> reordering, AML bug, you simply misread the ACPI spec and it did work for 
> Windows (the ACPI kernel maintainer likes to add the "compatibility" hack, 
> but it's just too intrusive to backport into your stable kernel release you 
> support), ...). But a modification in the DSDT is a one-liner and an obvious 
> fix.
> You desperately search for a flag to be able to make sure you do not risk to 
> break Windows...
> Now they have to ignore the bug. Bad for the vendor, bad for the customer, bad 
> for us (yet another complex "Windows compatibility" hack).

And then later we fix the bug and the Linux workaround starts breaking 
things. The vendor is unhappy. You can't even just key it off kernel 
versions, since distributions will backport arbitrarily large chunks of 
code (and if you doubt this, take a look at the sata tree in the RHEL 
kernel some time). 

> A general Linux flag is the way to start, everything more specific will/can 
> get embedded into this flag later if it makes sense (without any risk for the 
> vendors to break Windows). There are (I expect most) cases where embedding 
> stuff into if(linux) makes a lot sense. But Henrique and others are probably 
> right that we need something more fine grained later (in rare cases, e.g. the 
> in-kernel graphics driver issues).

There's no flag we can provide to indicate a desire for graphics 
POSTing. If vendors want to offer that, then they should provide an 
entry point that triggers it and a kernel driver that calls it. The 
policy for deciding whether or not to do this is far more complex than 
can be provided in-kernel.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Theodore Tso]

On Thu, Feb 21, 2008 at 04:41:21PM +0100, Thomas Renninger wrote:
> > OEMs that really want to modify the BIOS to recognize
> > OS interfaces that are in Linux should propose
> > new OSI strings that specify interfaces, not broad
> > categories of operating sytems; and in Linux we
> > shoudl use, or not use, those strings, as appropriate.
> > I've recently been in discussion with OEMs on exactly
> > this topic -- I'm sorry it didn't happen a year ago.
> So you mean "SLED 10 SP2", "UBUNTU supported version XY" strings?

No, no, no, no, no!

What part of "specify interfaces, not broad category of operating
sytems" didn't you understand?

So for example, if we if some vendor decides for some silly reason
that they must the Nvidia graphics chipsets, and Nvidia is the one
holdout which is lame about providing information so we can program
the video hardware correctly after a suspend/resume, maybe there is a
feature flag, OSI(LameNvidiaSuspendResume).  The suppose 6 months
later, someone manages to disassemble the Nvidia driver in some legal
jurisdiction where there is no DMCA nonsense, and so Linux is now
capable of dealing with the video card itself.  Now future kernels can
simply omit that very specific OSI string.

Just because we are saying that OSI(Linux) is bad, does not mean that
people are saying that OSI("SLED 10 SP2") is the right answer.  Hell,
no!  The right thing is something like OSI(LameNvidiaSusependResume).

					- Ted

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Thomas Renninger]

On Wed, 2008-02-20 at 17:32 +0000, Matthew Garrett wrote:
> Let's look at this differently. Most hardware is produced by vendors who 
> don't care about Linux. We need to make that hardware work anyway. The 
> only way we can achieve that is to be bug-compatible with Windows. 
> Therefore, any way in which Linux behaviour varies from Windows 
> behaviour is a bug. The only reason to export any indication that the 
> kernel is Linux is because our behaviour is not identical to Windows. 
> But, given that that's a bug, the solution should be to fix Linux and 
> not to encourage vendors to put workarounds in their firmware.

So to what Windows version are we compatible?

We currently return true for "Windows 2006".
According to drivers/acpi/utilities/uteval.c we return true for all of
these:

        "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 */

Stuff added for "Windows 2001 SP2" might break Windows 2006.
How do you want to handle this?
Do you want to remove lower versions at some time?
What about Longhorn or whatever coming up?
Then these strings might branch into a server and a workstation Windows,
to which one do you want to stay compatible, both again?
All this does not make sense and it does not work.

All this is an advantage for vendors who do not care about Linux, but it
makes life really hard for vendors who want to support it.

The _OSI interface is not thought for Linux kernel developers to stay
compatible with Windows.
It got invented for vendors being able to provide hot-fixes for their
BIOS for Operating Systems they are willing to support.

So what should a vendor do if he has a BIOS hotfix for Windows 2003
only. The fix workarounds an old W2003 AML bug. But this fix will break
Linux and Vista on his machine. For Vista he can take care, Linux will
break. And you are going to try to implement a workaround for an old
W2003 OS bug (after people got angry because their machine they bought
with Linux pre-loaded does not boot anymore after a BIOS update)...

Your scenario only makes sense for Windows 2006 vendor fixes but also
these are outdated soon, all this simply does not work...

   Thomas

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Matthew Garrett]

On Fri, Feb 22, 2008 at 03:07:42PM +0100, Thomas Renninger wrote:

> So to what Windows version are we compatible?

Microsoft has been very good at keeping backwards compatibility for this 
functionality, so the obvious aim is to be compatible with the current 
version of Windows and all previous versions. If necessary, we can 
switch to compatibility modes depending on whether the firmware requests 
XP or Vista or whatever.

> Do you want to remove lower versions at some time?

No.

> What about Longhorn or whatever coming up?

We aim to be compatible with it.

> Then these strings might branch into a server and a workstation Windows,
> to which one do you want to stay compatible, both again?

Whichever one the firmware asks for.

> All this does not make sense and it does not work.

It makes perfect sense and I've no reason to think it doesn't work.

> All this is an advantage for vendors who do not care about Linux, but it
> makes life really hard for vendors who want to support it.

No! We have the choice between providing a benefit to a subset of 
vendors at the cost of never being able to fix bugs, or just making 
everything work. Given the choice between making everything work and 
making Lenovo work, I'll go for making everything work.

> The _OSI interface is not thought for Linux kernel developers to stay
> compatible with Windows.
> It got invented for vendors being able to provide hot-fixes for their
> BIOS for Operating Systems they are willing to support.

No! _OSI is (according to the spec) there to enable vendors to support 
*features* provided by specific OSs, not to work around bugs in that OS. 
What does an _OSI of Linux mean? We don't have a well-defined feature 
set. We don't have a stable set of bugs. Our development model is 
inherently different from Windows, and providing this information just 
makes no sense.

> So what should a vendor do if he has a BIOS hotfix for Windows 2003
> only. The fix workarounds an old W2003 AML bug. But this fix will break
> Linux and Vista on his machine. For Vista he can take care, Linux will
> break. And you are going to try to implement a workaround for an old
> W2003 OS bug (after people got angry because their machine they bought
> with Linux pre-loaded does not boot anymore after a BIOS update)...

Fine. So we define different behaviour depending on whether the firmware 
asks for Vista or not. This isn't rocket science.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Len Brown]

On Thursday 21 February 2008 12:15, Theodore Tso wrote:
> On Thu, Feb 21, 2008 at 04:41:21PM +0100, Thomas Renninger wrote:
> > > OEMs that really want to modify the BIOS to recognize
> > > OS interfaces that are in Linux should propose
> > > new OSI strings that specify interfaces, not broad
> > > categories of operating sytems; and in Linux we
> > > shoudl use, or not use, those strings, as appropriate.
> > > I've recently been in discussion with OEMs on exactly
> > > this topic -- I'm sorry it didn't happen a year ago.
> > So you mean "SLED 10 SP2", "UBUNTU supported version XY" strings?
> 
> No, no, no, no, no!
> 
> What part of "specify interfaces, not broad category of operating
> sytems" didn't you understand?
> 
> So for example, if we if some vendor decides for some silly reason
> that they must the Nvidia graphics chipsets, and Nvidia is the one
> holdout which is lame about providing information so we can program
> the video hardware correctly after a suspend/resume, maybe there is a
> feature flag, OSI(LameNvidiaSuspendResume).  The suppose 6 months
> later, someone manages to disassemble the Nvidia driver in some legal
> jurisdiction where there is no DMCA nonsense, and so Linux is now
> capable of dealing with the video card itself.  Now future kernels can
> simply omit that very specific OSI string.
> 
> Just because we are saying that OSI(Linux) is bad, does not mean that
> people are saying that OSI("SLED 10 SP2") is the right answer.  Hell,
> no!  The right thing is something like OSI(LameNvidiaSusependResume).


Ted speaks the truth.

Indeed, this is exactly the issue with the Dell M4300.

Dell executes BIOS re-post on OSI(Linux) for the benefit of
text-mode video restore, and for the case where nv is used
instead of the binary nvidia driver that knows how to do this.

Why is that bad?
Well, consider why Dell doesn't execute that BIOS code unconditionally...
It is because it would make Windows resume speed uncompetitive.

So when Linux nv gets fixed (like i915 was) so that it can restore
video w/o the BIOS, how to you un-do the damage?
With OSI(Linux) you can't -- Linux will be at a permanent
disadvantage to Windows on that platform _forever_.

However, if nv were changed to call an I/F in Linux/ACPI
that says "please add OSI(LameNvidiaSusependResume)"
and Dell's BIOS executed the video BIOS restore only when
that was set, then a future smarter nv could stop using that crutch
and Linux would no longer be at a disadvantage.

-Len

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Len Brown]

On Thursday 21 February 2008 10:41, Thomas Renninger wrote:
> On Thursday 21 February 2008 09:41:13 you wrote:
> > Thomas,
> > Thanks for the note.
> > Please read the messages on linux-acpi with "dmi" in the subject
> > for some background.

> Can you be a bit more specific. Grepping for "dmi" is a bit verbose on the 
> linux-acpi list.

Sure, search messages from me in the last two months with "dmi" in the subject.

BTW. here is an example of OSI(Linux) breaking Linux:
http://bugzilla.kernel.org/show_bug.cgi?id=7787

> > yes, OSI(Linux) was enabled by default through 2.6.22
> > and was disabled by default starting in 2.6.23.
> >
> > The reason it has come up recently is because
> > it got into a reference BIOS -- and I'm sorry
> > to admit that I was a party to that -- I
> > wasn't thinking.
> >
> > Tomas Carnecky's reply is 100% correct.
> > We can't support OSI(Linux) any more than we
> > could support _OS="Linux", or Microsoft
> > could support OSI(Windows) -- particularly
> > on an OS that changes as fast as Linux does.
> > To do so would in some cases put Linux at
> > a permanent disadvantage to competing operating systems.

> No, not providing an interface at all is a disadvantage, a permanent one.
> 
> You all look at this too much from the kernel point of view:
> You are a vendor and you want to provide a BIOS update, because on the model 
> you sold with Linux on it, there is a bug. For some reason Linux is not 100% 
> compatible to Windows and the bug does only exist on Linux.
> But you still have to support Windows on that machine and unfortunately this 
> machine got sold with Windows 10x more often than with Linux.
> The bug is rather complicated to fix/workaround through the OS (E.g. suspend 
> reordering, AML bug, you simply misread the ACPI spec and it did work for 
> Windows (the ACPI kernel maintainer likes to add the "compatibility" hack, 
> but it's just too intrusive to backport into your stable kernel release you 
> support), ...). But a modification in the DSDT is a one-liner and an obvious 
> fix.
> You desperately search for a flag to be able to make sure you do not risk to 
> break Windows...
> Now they have to ignore the bug. Bad for the vendor, bad for the customer, bad 
> for us (yet another complex "Windows compatibility" hack).
>
> > Yes, we are attempting to close Pandora's box.
> Too late and IMO there is nothing bad about it.

Not only is there something bad about it,
the size and duration of the badnessa are both unbounded.

We went through this before when we changed
ACPI_OS_NAME to "Microsoft Windows NT" from "Linux".

We need to learn from history.

> > I think we'll be successful, though we have to handle the
> > Dell and Lenovo systems which actually use OSI(Linux)
> > on purpose.
> > Everybody else appears to be using it 
> > by mistake, sometimes with no effect,
> > sometimes with negative effect.
> Are you sure, they use it by mistake?
> Again, think from a vendor's point of view...
> What I expect happened here:
> Vendors thought about better Linux support. Some already chose a distribution 
> which (most common should be Ubuntu here, It's Dell, already Acer? and 
> others?) They pre-load it with a specific, probably a rather stable release 
> and sell their laptops with it. And they have to provide support for it, at 
> least for the release they sold it with.
> 
> I expect the first thing they did when thinking about Linux support is that 
> they added something similar like:
> Name (Linx, 0)
> ...
> if (_OSI("Linux"))
>    Store(1, Linx)
> 
> to their BIOSes, the same they do for Windows'es they have to support.
> They even may have verified it working... the "NOP".
> Now if there pop up problems, they can and will use this to provide Linux 
> specific BIOS fixes with code that is only processed on Linux, because they 
> cannot risk to break Windows.
> 
> If you rip this out now you will see:
>   - white/black listed NOPs that break after a BIOS update with later
>     kernels
>   - No BIOS updates for Linux at all in this area (and this is what I mean
>     with permanent disadvantage)

Outside of the development community, "BIOS update" is virtually an oxymoron.

> > No, the DMI list is not large,
> It is very confusing.
>
> > it is mostly comments and it is __init.
> That is not really important.

If there is a problem with the blacklist,
please bring it to my attention.

> > I _strongly_ urge you to not fork from
> > the .stable and mainline kernel in this area.

> Matthew's arguments are quite interesting.
> I still disagree with:
>   - simply ripping it out (at least do it soft)
>   - Remove all possibilities for vendors who want support Linux
>     to provide safe, only Linux affecting BIOS updates, just for
>     the sake of "being Windows compatible"
> 
> The strongest argument: I agree that they of course should contribute their 
> code and start working on the kernel, provide software updates etc.
> But those guys do not have to share much, anyway:
> (Some guessing now): Asus, Acer, Lenovo, Dell,...: have to make sure that they 
> buy and put hardware into their machines from companies that work on Linux 
> now. This is where we will see most advantages. They do not manufacture most 
> HW components themselves (network/wlan/sound/... cards). They manufacture or 
> at least have direct control over their BIOS, though. So this kind of hot-fix 
> is most convenient for them (or may be the only possibility for them).
>
> > OEMs that really want to modify the BIOS to recognize
> > OS interfaces that are in Linux should propose
> > new OSI strings that specify interfaces, not broad
> > categories of operating sytems; and in Linux we
> > shoudl use, or not use, those strings, as appropriate.
> > I've recently been in discussion with OEMs on exactly
> > this topic -- I'm sorry it didn't happen a year ago.

> So you mean "SLED 10 SP2", "UBUNTU supported version XY" strings?

No, I mean "Extended Address Space Descriptor"

> While this would be helpful for vendors on shortterm, they would realize soon, 
> that their customers get angry after updating to an unsupported, brand-new 
> kernel/distribution. This is exactly what we do not want to have (and what 
> could happen soon).
> 
> IMO osi=linux should stay (must stay now!).
> Your concerns that the vendors are messing up their BIOSes, so that this has 
> to be workarounded in later kernels etc. is utopistic.
> Vendors who are using such flags in their BIOSes want their machines to run 
> fine on Linux forever. They do not add ugly stuff in there on purpose. 
> Explain them how to use it. They should stick to the specifications, ask on 
> acpi list if in doubt. We should make up a documentation: "Guide for Linux 
> ACPI BIOS updates", ...
>
> The whole problem here is that those guys who are affected have never been 
> asked...
> Shouldn't there be some Dell activity on some Linux/Ubuntu lists now? I bet 
> every vendor will tell you that he wants to have such a thing. Find out some 
> people who are in charge for Linux and invite them for a discussion.
> A general Linux flag is the way to start, everything more specific will/can 
> get embedded into this flag later if it makes sense (without any risk for the 
> vendors to break Windows). There are (I expect most) cases where embedding 
> stuff into if(linux) makes a lot sense. But Henrique and others are probably 
> right that we need something more fine grained later (in rare cases, e.g. the 
> in-kernel graphics driver issues).

If you are having discussions with vendor BIOS writers,
please be encouraged to put them in direct contact with me.
I'm in touch with several, and they generally prefer
private communication versus open discussion on the list.

thanks,
-Len

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Thomas Renninger]

On Fri, 2008-02-22 at 18:10 +0000, Matthew Garrett wrote: 
> On Fri, Feb 22, 2008 at 03:07:42PM +0100, Thomas Renninger wrote:
> 
> > So to what Windows version are we compatible?
> 
> Microsoft has been very good at keeping backwards compatibility for this 
> functionality, so the obvious aim is to be compatible with the current 
> version of Windows and all previous versions. If necessary, we can 
> switch to compatibility modes depending on whether the firmware requests 
> XP or Vista or whatever.
> 
> > Do you want to remove lower versions at some time?
> 
> No.
> 
> > What about Longhorn or whatever coming up?
> 
> We aim to be compatible with it.
You want to be compatible with all Windowses that exist and ever will
get published?
Impossible!

> > Then these strings might branch into a server and a workstation Windows,
> > to which one do you want to stay compatible, both again?
> 
> Whichever one the firmware asks for.
> 
> > All this does not make sense and it does not work.
> 
> It makes perfect sense and I've no reason to think it doesn't work.
> 
> > All this is an advantage for vendors who do not care about Linux, but it
> > makes life really hard for vendors who want to support it.
> 
> No! We have the choice between providing a benefit to a subset of 
> vendors at the cost of never being able to fix bugs, or just making 
> everything work. Given the choice between making everything work and 
> making Lenovo work, I'll go for making everything work.
But you will fail for sure.
It is so realistic like: "We aim to be compatible with all Windows
versions that ever existed."
Supporting the one and the other version can and in reality is mutually
exclusive.

> > The _OSI interface is not thought for Linux kernel developers to stay
> > compatible with Windows.
> > It got invented for vendors being able to provide hot-fixes for their
> > BIOS for Operating Systems they are willing to support.
> 
> No! _OSI is (according to the spec) there to enable vendors to support 
> *features* provided by specific OSs, not to work around bugs in that OS. 
> What does an _OSI of Linux mean? We don't have a well-defined feature 
> set. We don't have a stable set of bugs. Our development model is 
> inherently different from Windows, and providing this information just 
> makes no sense.
Invented was wrong. After spec it indeed has another meaning, but you
unfortunately are right with: Microsoft defines the standards by their
implementations. In this case it probably were the vendors who need this
hook asking Microsoft to provide it (and we remove it for Linux...).

It is used by vendors being able to provide hot-fixes for their
BIOS for Operating Systems they are willing to support.
Please go through through some OSI declarations. I've done it (see at
the end), I just went through some for 20 minutes to get a bit of an
impression what kind of features and what kind of hacks have been added.
And I could only identify hacks (needs more evaluating, as soon as more
complicated functions are invoked it's getting difficult).
So you do not try to be feature, but bug compatible with all kind of
Windows versions.

I agree it made sense some years ago, when it was not clear for what
_OSI is/will get used by vendors and Microsoft, but now it leads to a
totally undefined behavior and confusion.

While _OSI("xy") can return true for several strings, current BIOSes
rely on the fact that only one Windows OS string returns true, e.g.
"Windows 2001 SP1". For most it fortunately does not matter as they all
override one variable to store the information. But not all! E.g. all
ThinkPads seem to store this in different values:
\WNTF (Windows NT), \WXPF (Windows XP), \WSPV (Window XP Service Pack
version), \WVIS (Vista), \WMEF (Millenium Edition), \W98F (98).

And they add different BIOS workarounds/hacks. The BIOS developers rely
on that only either of these are set (or WXPF + Service Pack variable).
So returning true for all kind of Windows Versions is a really bad idea
and we should move away from this asap.

Also removing old ones and switch to a new Version if a new one is used
(e.g. remove "Windows 2006" and switch to "Windows Longhorn" as soon as
it is available) does not make sense.

The problem is that _OSI is not used for features, but for BIOS fixes.
I expect it works like that:
It seems all kind of ASL templates are copied together to a BIOS, and
made work as they should.
Then OSI hooks are added for all Windows OS it should support.
Later at a specific time of their product (when QA is heavily testing
each OS), they are able to only add hot-fixes for a specific OS (if only
a specific OS is affected) without the need of revalidating whether
other OSes are still running fine.

Len, can you put the acpidumps you received on a public ftp server, pls.
This should make it easy for others to reproduce or invalidate my
findings.

IMO there is only one long term solution: 
Start removing old OSI strings returning true (all but "Windows 2006").
This should be no functional change on most machines.
On others (e.g. ThinkPads, probably more) chances are high, that we get
some things fixed up for free.

Then we should remove the "Windows 2006" string and fix up the rest.
First, affected DSDTs should be evaluated in more detail to get a
picture how much could/would break.

If, and I doubt there are much, OSI is used for feature identification
or really fixes ASL statements in a sane way (hot-fixes are mostly ugly
hacks like "disable device capability" and similar..), those rare
machines can get a dmi entry to return true for the very Windows Version
that has the fix included: "Windows 2006", "Windows 2001 SP1".

> > So what should a vendor do if he has a BIOS hotfix for Windows 2003
> > only. The fix workarounds an old W2003 AML bug. But this fix will break
> > Linux and Vista on his machine. For Vista he can take care, Linux will
> > break. And you are going to try to implement a workaround for an old
> > W2003 OS bug (after people got angry because their machine they bought
> > with Linux pre-loaded does not boot anymore after a BIOS update)...
> 
> Fine. So we define different behaviour depending on whether the firmware 
> asks for Vista or not. This isn't rocket science.

Here some examples:

===========================================
OSTB is the OS (only add this sleep if BIOS version is older than xy):
If (LAnd (LEqual (\_SB.PCI0.LPCB.INF, 0x01), LNot (LLess (\_SB.OSTB,
0x04))))
{
     Sleep (0x01F4)
}


I saw similar conditions for aquire and release statements. Looks like
sleep/serialization workarounds are needed on OSTB lower than 0x4?

===========================================
TPOS is the OS, maybe we should try to remove some of the early W$
Versions on PNP broken machines, I could imagine ACPI resource
management was rather broken on early W$ versions and we could fix up
some bugs:
Method (_CRS, 0, NotSerialized)
{
      If (LNot (LLess (TPOS, 0x04)))
      {
            CreateDWordField (MSRC, 0x1C, BARX)
            CreateDWordField (MSRC, 0x20, GALN)
            Store (0x1000, GALN)
            Store (\_SB.PCI0.Z009, Local0)
            And (Local0, 0xFFFFFFF0, BARX)
      }
      Return (MSRC)
}



===========================================
OSTP evaluates OSI, OSTB is the os version, again a resource fixup:

Name (_HID, EisaId ("PNP0A03"))
Method (_CRS, 0, NotSerialized)
...
\_SB.OSTP ()
CreateDWordField (BUF0, 0x3E, VLEN)
CreateDWordField (BUF0, 0x36, VMAX)
CreateDWordField (BUF0, 0x32, VMIN)
ShiftLeft (VGA1, 0x09, Local0)
Add (VMIN, Local0, VMAX)
Store (Local0, VLEN)
Concatenate (GMEM (0x00), BUF0, Local1)
Concatenate (\_SB.PCI1.GETM (0x00), Local1, Local2)
If (LOr (LEqual (OSTB, 0x01), LEqual (OSTB, 0x02)))
{
     Concatenate (GMEM (0x01), Local2, Local3)
     Return (Local3)
}
Else
{
     Return (Local2)
}



===========================================
My favorite one (MSOS is the OS):
Method (CMRD, 1, NotSerialized)
{
    Acquire (SMIM, 0xFFFF)
    Store (Arg0, Local0)
    And (Local0, 0x7F, Local0)
    Store (Local0, SMID)
    Store (0x84, SMIC)
    Store (0x85, SMIC)
    Store (SMID, Local0)
    Release (SMIM)
    Return (Local0)
}

Method (HACK, 0, NotSerialized)
{
    Store (CMRD (0x37), Local0)
    And (Local0, 0xDF, Local0)
    CMWR (0x37, Local0)
    If (LEqual (MSOS, 0x04))
    {
        Store (CMRD (0x6F), Local0)
        Or (Local0, 0x04, Local0)
        CMWR (0x6F, Local0)
        Return (One)
    }
    Else
    {
        Store (CMRD (0x6F), Local0)
        And (Local0, 0xFB, Local0)
        CMWR (0x6F, Local0)
    }
}
===========================================



===========================================
Only acquire mutex and sleep if OS is newer than xy.
In this case it may make sense to provide a flag that we are
a newer Windows OS. But I am not sure.
If (LGreaterEqual (\WNTF, 0x02))
{
     Acquire (MCPU, 0xFFFF)
}
If (LGreaterEqual (\WNTF, 0x02))
{
     Sleep (0x64)
}



Also the behavior is totally undefined (as said above).
Some implementations override the previously set ones.
If the latest OS (in this case Windows 2006) is the last one, it's fine,
but this is pure luck that "Windows 2006" is the last one and on the
next BIOS Linux might get identified as Windows 2001...

If (_OSI ("Linux"))
{
    Store (0x03E8, OSYS)
}
If (_OSI ("Windows 2001"))
{
    Store (0x07D1, OSYS)
}
If (_OSI ("Windows 2001 SP1"))
{
    Store (0x07D1, OSYS)
}
If (_OSI ("Windows 2001 SP2"))
{
    Store (0x07D2, OSYS)
}
If (_OSI ("Windows 2006"))
{
    Store (0x07D6, OSYS)
}


Others do not override, but set different variables for the OS (quite
seldom, but like that we get all the added hacks...):


If (LEqual (\SCMP (\_OS, "Microsoft Windows"), Zero))
{
    Store (0x01, \W98F)
}
Else
{
     If (CondRefOf (\_OSI, Local0))
     {
         If (\_OSI ("Windows 2001"))
         {
                Store (0x01, \WNTF)
                Store (0x01, \WXPF)
                Store (0x00, \WSPV)
         }
     If (\_OSI ("Windows 2001 SP1"))
     {
         Store (0x01, \WSPV)
     }

     If (\_OSI ("Windows 2001 SP2"))
     {
         Store (0x02, \WSPV)
     }

     If (\_OSI ("Windows 2006"))
     {
         Store (0x01, \WVIS)
     }
}
Else
{
     If (LEqual (\SCMP (\_OS, "Microsoft Windows NT"), Zero))
     {
         Store (0x01, \WNTF)
     }
     Else
     {
          If (LEqual (\SCMP (\_OS, "Microsoft WindowsME: Millennium
Edition"), Zero))
     {
          Store (0x01, \WMEF)
          Store (0x01, \W98F)
     }
}

The latter is done on ThinkPads.
I wonder whether not returning _OSI("Windows XY") fixes the shutdowns on
older ThinkPads. Those seem to run at an offset of 20 C above the real
temperature (could be a little EC write on Windows OS xy SP z, since
BIOS update W...).
And the right fix for it is not to blacklist ThinkPads to not return
true for all Windows versions, but to remove this unconditionally.

    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

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Thomas Renninger]

On Thu, 2008-02-21 at 08:51 -0500, Theodore Tso wrote:
> On Thu, Feb 21, 2008 at 09:15:32AM +0000, Matthew Garrett wrote:
> > 
> > Offering OSI(Linux) makes a statement about our implementation - we're 
> > telling the firmware that it behaves in a certain way. That lets vendors 
> > start depending on that behaviour, and if that behaviour turns out to be 
> > different to Windows then we never get to fix that behaviour. Fine for 
> > vendors that have special-cased their firmware, bad for the vast 
> > majority of systems.
> 
> Exactly, that's the problem.  Suppose we put in an OSI(Linux), and
> Lenovo, thanks to the fact that they are working with Novell, puts in
> a special case hack just for whatever version of SLES they happen to
> be testing with.  Well, great.  Now suppose that three other laptops
> from different manufacturers (say, Sony, Fujitsu, and Asus) do things
> differently, the Windows way, and someone posts a patch to the ACPI
> drivers (and it might not and probably won't be the Thinkpad specific
> thinkpad_acpi.c file) which changes things so that it works for Sony,
> Fujitsu, et. al. --- and in the process, it breaks things for Lenovo,
> because the Lenovo is doing something special based on OSI(Linux)
> thanks to their special collaboration with Thomas Renniger and Novell.
> Oops.  Now we have a mess, and we have to start having special
> DMI-based blacklists and whitelists, and life generally sucks.
I doubt it. With your approach you end in a dmi black/whitelisting mess
and you violate the behavior BIOS developers seem to expect (that is
what we want to be compatible with, what BIOS developers write down,
right?).

Return true for OSI("Linux") for some T61 is wrong. It depends on the
BIOS (latest X61 might not have it yet, but will later, etc.), trying to
identify it is pretty much impossible (you can grep for "Linux" through
the memory where the table lies, yet more ugly than the current
"solution".
Probably the same for Dell and as said others might fill this with BIOS
updates.
The interface has been added and now it has to be kept.
And even if it has not been added, vendors are using it, as this has
been identified to be be more important than specs: Provide it.

> It would be much better if we define feature-specific OSI() strings
> that have well defined meanings for each place where Lenovo has to do
> something different than What Happens With Windows
Yes. But at the time the BIOS fix should be released, these
feature-specific OSI strings do not exist. And it takes at least a
kernel iteration until it comes into mainline kernel for sure. So you
want the vendor to wait half a year before the Linux BIOS hot-fix is
released?
They need if(OSI("Linux"). As soon as it is clear what the
fix/workaround (or even missing feature) is about, it can be discussed
to include an _OSI("feature") string to the kernel.
Vendors who care for linux would probably have no problem with updating
their fix in a later BIOS revision then(still embedded in linux only, to
not cause Windows regressions of course):
if(_OSI("Linux"){
   Store(0x1, fix1)
   Store(0x1, fix2)
}
to something like:
if(_OSI("Linux"){
   Store(0x1, fix1)
   if(_OSI("!Feature XY")
       Store(0x1, fix2)
}


>  --- especially for
> stuff which is generic, since all laptop manufactuers need to
> interoperate with whatever cr*p Windows ship.  
As said you cannot interoperate with all crap all Windows Versions ship.
They fix up things... and we are trying to stay compatible with the
bugs, this does not make any sense.
> At the end of the day,
> since Intel was originally too lazy to ship an ACPI conformance test
> suite, like it or not, Windows *has* become the APCI conformance test
> suite, and all laptop manufacturers (at least for today) must bow to
> the might and power which is the market share of Microsoft.
Wrong.
Currently there is a move to also ship laptops with Linux. It's not only
Lenovo, but also Dell and others.
These vendors can (if not cut down by OS too much) support their
machines. They are supporting driver development and they must make sure
that every single bit of the HW is running fine with Linux.
E.g. Lenovo released some native SATA and USB fixes for their BIOS
recently, you probably do not want to miss them.
If people have some spare time, they can go back some BIOS versions
before and fix up the drivers. But do not let vendors who care about
Linux force to
a) Duplicate bugs they already have to do for Windows (disable
   HW capability for a SP or whatever they add)
b) Not be able to provide BIOS fix-ups (e.g. if ASL code is needed) for
   Linux

You do not get machines fixed by that if the vendor does not care about
Linux (with the next _OSI("Windows 200X") hack he adds, things will
break anyway as these guys do not do a single test on Linux).

You want customers who buy a Linux machine (and I also would insist that
it is running just fine on Linux then), to open bug reports on
bugzilla.kernel.org so that they/you are able to debug problems that
"might" happen on machines who's vendors don't give a Cent for Linux?

No that is not working, it's working like that:
As soon as the vendors who are currently start to sell Linux with their
laptops are only gaining say 2% market share because of some more sold
machines to Linux users. Then the others will follow.
They are forced to use HW which uses open drivers and they have to make
sure their BIOS is half way compatible with Linux (if not they have to
modify it -> _OSI("Linux") needed for BIOS updates!).

This makes much more sense and is more realistic than trying to be
compatible with Windows or even all Windows Versions and it should get
supported as much as possible.

   Thomas

Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Matthew Garrett]

On Tue, Feb 26, 2008 at 05:26:45PM +0100, Thomas Renninger wrote:

> Return true for OSI("Linux") for some T61 is wrong. 

I agree, and I'd rather not have the whitelisting.

-- 
Matthew Garrett | mjg59@srcf.ucam.org