Ted, Henrique, Matthew,
Thank you for your wise words.
Here is my plan.
1. notify Intel mobile BIOS group that Linux will STOP answering "yes" to OSI(Linux),
that they should STOP using OSI(Linux) in their BIOS, and that Linux will
complain about them when they do.
I believe this team is the "upstream" cause of the majority of
OSI(Linux) in the field today.
I did this last year -- and they were not happy about it.
The laptops vendors were not happy either.
However, as it is unsupportable in the long run, I assert we have no choice.
Yes, we need a mitigation plan, for Linux tries to be Windows compatible,
but the reality is that we use the platform differently in many areas.
Graphics and platform specific drivers top the list,
and a long list of platform workarounds fill it out.
I am okay with defining OSI strings for the benefit of BIOS vendors that
need to know about Linux capabilities. But the string must
identify that specific capability (or lack of a capability).
The first on the list would be a way to tell the BIOS that it should
restore video on S3 resume. This is off on Windows b/c it is faster
for a native driver to do it. But Linux doesn't yet have native drivers
that can do this. So we need to be able to ask the BIOS to do this for us
until we do -- and then we need to be able to _stop_ asking the BIOS
when we have native graphics driver support in place. (This is an example
of why "Linux" is a poor choice for a capability string -- once you use it,
when can you _stop_ using it?)
2. Transition Linux from OSI(Linux) to !OSI(Linux)
Linux-2.6.21 was the last kernel with OSI(Linux) by default w/o complaint.
Linux-2.6.22 was the last kernel with OSI(Linux) by default, but it complains.
Linux-2.6.23 was the first kernel with !OSI(Linux) by default, and it still complains.
3. Clean up any wreckage
That is where we are now. The goal is to identify the products that
really do need OSI(Linux) and help them keep shipping.
There are 3 types of OSI(Linux) users:
1) most laptops with OSI(Linux) inherited it from the refernece code
and don't actually use it for anything.
Linux will complain about these, until we get their DMI and
tell Linux to stop complaining. But with or without DMI,
OSI(Linux) is off for these systems.
2) laptops where OSI(Linux) causes a failure.
This is the case I'm most worried about, because
it is just like the _OS=Linux issue in the old days,
which means it has unbounded risk of failure in the field.
As the default in 2.6.23 and later is to disable OSI(Linux)
these systems work by default going forward,
and we just need their DMI to quiet them up,
like we did for case #1. I do actually use an
OSI-disable DMI hook for these rather than an OSI-ignore DMI,
in case somebody wants to build the kernel with it enabled by default.
3) OSI(Linux) added by the vendor that actually makes a Linux SKU work.
The good/bad news is that there are very few real laptop Linux SKUs,
so indentifying them and dealing with them is finite.
As OSI(Linux) is disabled by default today, any vendor
that wants it to be enabled for their product will have
to get a change into Linux, whether it be a bootparam
or a white-list entry. I think having this barrier to
entry is good, in that it is motivation to avoid doing the wrong thing.
thanks,
-Len
ps. I say laptops above. I've seen OSI(Linux) on a few Dell desktops,
but otherwise I've only seen it spread to laptops.
-
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
