On Mon, 2008-02-18 at 16:17 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 18 Feb 2008, Thomas Renninger wrote:
> > The problem is that OSI is used by Windows to pass the exact Windows
> > (not OS) version they are running, this function should be called WOSI.
> > We of course want to run on the latest fix-ups here and should pass
> > "Windows 2006" (or whatever latest string there exists).
> >
> > IMO we need the same for Linux.
> > We even have the advantage, that the string in LOSI(String) makes some
> > sense, e.g. 2.6.24, so why not use LOSI(int, int, int)
> > How the exact interface might look like I am not sure, just an idea.
>
> Looks quite a bad idea IMO. 2.6.24 means what? SuSE's? Mainline's?
> Debian's? At what patch level? With which user patches tacked on top? And
> at what level of userspace support (X.org can make a LOT of difference
> here)?
Every distribution is based on a specific kernel, right?
Most stuff that gets fixed by these workarounds would make no sense to
backport, because backports are much too intrusive, e.g.:
- AML interpreter workarounds
- suspend to ram (s3bios or kernel graphics driver support)
- suspend order
- FSC V5505 does not like a specific EC write done with
Osi="Windows 2006" -> easy to workaround for the vendor, they
already implement "Linux" as Osi string
http://bugzilla.kernel.org/show_bug.cgi?id=9939
- Lenovo brightness (Internal Intel graphics card needs kernel
graphics driver supported for their BQC, BCL, BCM implementation)
This will never ever be possible to backport
- Dozens more...
> No, if you are going to go about that, use OSI to ask about specific support
> you need, like Len said. Yes, this might mean a lot of OSI strings.
Not for us, we can just pass the kernel version and check for
greater/less.
> > A)
> > Vendors *must* have a flag for Linux to be able to provide proper
> > support for multiple kernels and to be able to provide easy and riskless
> > fixes for Linux at all.
>
> You need it to be more fine-grained than that, a LOT more fine-grained.
No you need not. It would be fine, but it's better than nothing.
> > I expect we now have this problem because nobody (including myself)
> > never dreamed of that it could ever happen that a vendor adds Linux
> > specific AML code.
>
> Then WTF did we start shipping an OSI(Linux) string in the first place?
> Don't tell me it was done just for the heck of it.
Right..., it's invoked by BIOS and the kernel can return true on
multiple strings.
It's a good idea, not perfect yet. Removing it with the dmi white/black
list..., puhhhh, IMO not a good idea.
> > But now that it happens we should react quickly and come up with a
> > robust interface for the future...
>
> Len already explained what is needed, and I added how to do it in a way that
> it would be accepted from my experience with vendors.
Len wants to get rid of it after BIOS vendors finally started to use it, I got that now.
And what should be the replacement?
This whole dmi white/black listing to use osi(linux) or not cannot be
the final solution?
I didn't really realize what is going on, I did a short double delete on
most osi=linux mails of the past weeks..., what was your way that you
think gets accepted by vendors?
Vendors need a knob for their BIOS fixes, that should be proven since so
many are using osi=linux for some time now (since some came up with
pre-loads I expect...).
> Basically, it needs to be fine-grained and function-specific, AND it must be
> allow for near-perfect backward and forward compatibility or it will be a
> lot more difficult to see it get any use.
?!?
It simply must be knob which vendors can use to place AML code in for
which they can be sure that it's only processed on Linux. That would
vendors already help a lot to release a BIOS fix (for which everybody
screams: those broken BIOS'es AML code does not get fixed up by the
vendors...).
This will reduce the QA vendors have to do: Only need to test one OS
when releasing a BIOS fix.
Or for most it's an argument to do a fix for Linux *at all*. I wouldn't
risk any line of code for an OS that runs on 5% of my sold machines...,
maybe if it's "if(linux)" embedded. And fact is, there are not much
laptop models sold on which Windows is not the most common used
Operation System (Macs maybe...).
So either you get them a reasonable possibility to fix their BIOSes or
you end up blacklisting forever.
This is what we do for years, right?
We do it that way, because Windows is doing it on that machine..., it
breaks some others... then better do the middle of it, or better dmi
blacklist the one and the other machine...
Sorry, but this:
"ACPI: add DMI to enable OSI(Linux) on ThinkPad T61"
cannot be the solution. A blacklist for Linux specific BIOS
workarounds...
Why not moving these very machine specific workarounds into the BIOS,
this is what we always wanted, get it fixed in the BIOS?
Or even better, the vendors already do some QA on it and make sure that
the machine works perfectly with the latest kernel xy.
> > > Now, the real test will be if we ask for something that would require
> > > changing their Windows drivers. I sure hope they would do it, but...
> > Yep nobody would ever do this.
>
> I have some doubts about the "nobody", but you'd have to present a heck of a
> good case.
>
> BTW, I am perfectly happy with OSI(Linux) being used to disable crap that is
> only relevant to work around *bugs* in windows drivers. But that's not how
> most vendors use it.
I am already perfectly happy to disable crap that just makes the machine
work perfectly with the latest kernels and this is what these guys are
doing.
Maybe I just missed it, but there is no replacement for osi=linux vendor
workarounds decided/discussed yet?
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
