public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Matthew Garrett <mjg59@srcf.ucam.org>
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: Wed, 20 Feb 2008 19:21:57 +0100	[thread overview]
Message-ID: <1203531717.6019.324.camel@queen.suse.de> (raw)
In-Reply-To: <20080220173248.GA22709@srcf.ucam.org>

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


  reply	other threads:[~2008-02-20 18:21 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 [this message]
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
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=1203531717.6019.324.camel@queen.suse.de \
    --to=trenn@suse.de \
    --cc=aystarik@gmail.com \
    --cc=hmh@hmh.eng.br \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --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