From: Len Brown <lenb@kernel.org>
To: Theodore Tso <tytso@mit.edu>
Cc: Thomas Renninger <trenn@suse.de>,
linux-acpi <linux-acpi@vger.kernel.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
"Starikovskiy, Alexey Y" <aystarik@gmail.com>
Subject: Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
Date: Fri, 22 Feb 2008 18:36:20 -0500 [thread overview]
Message-ID: <200802221836.20421.lenb@kernel.org> (raw)
In-Reply-To: <20080221171501.GA17592@mit.edu>
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
next prev parent reply other threads:[~2008-02-22 23:37 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-20 1:44 Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement Thomas Renninger
2008-02-20 10:31 ` Tomas Carnecky
2008-02-20 13:14 ` Henrique de Moraes Holschuh
2008-02-20 15:31 ` Thomas Renninger
2008-02-20 17:32 ` Matthew Garrett
2008-02-20 18:21 ` Thomas Renninger
2008-02-20 18:46 ` Matthew Garrett
2008-02-20 18:23 ` Henrique de Moraes Holschuh
2008-02-20 18:49 ` Matthew Garrett
2008-02-21 3:13 ` Henrique de Moraes Holschuh
2008-02-21 5:31 ` Sergio Monteiro Basto
2008-02-21 15:55 ` Henrique de Moraes Holschuh
2008-02-21 9:15 ` Matthew Garrett
2008-02-21 13:51 ` Theodore Tso
2008-02-21 14:30 ` Matthew Garrett
2008-02-21 14:48 ` Alexey Starikovskiy
2008-02-21 14:55 ` Matthew Garrett
2008-02-21 15:07 ` Alexey Starikovskiy
2008-02-21 15:50 ` Henrique de Moraes Holschuh
2008-02-26 16:26 ` Thomas Renninger
2008-02-26 16:31 ` Matthew Garrett
2008-02-22 14:07 ` Thomas Renninger
2008-02-22 18:10 ` Matthew Garrett
2008-02-26 16:26 ` Thomas Renninger
2008-02-21 8:41 ` Len Brown
2008-02-21 15:41 ` Thomas Renninger
2008-02-21 15:58 ` Matthew Garrett
2008-02-21 17:15 ` Theodore Tso
2008-02-22 23:36 ` Len Brown [this message]
2008-02-23 0:06 ` Len Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200802221836.20421.lenb@kernel.org \
--to=lenb@kernel.org \
--cc=aystarik@gmail.com \
--cc=hmh@hmh.eng.br \
--cc=linux-acpi@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=trenn@suse.de \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox