public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Thomas Renninger <trenn@suse.de>
Cc: Len Brown <lenb@kernel.org>,
	linux-acpi <linux-acpi@vger.kernel.org>,
	Theodore Tso <tytso@MIT.EDU>,
	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:10:00 +0000	[thread overview]
Message-ID: <20080222181000.GB32623@srcf.ucam.org> (raw)
In-Reply-To: <1203689263.4995.81.camel@queen.suse.de>

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

  reply	other threads:[~2008-02-22 18:10 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 [this message]
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
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=20080222181000.GB32623@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=aystarik@gmail.com \
    --cc=hmh@hmh.eng.br \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.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