Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Thu, Feb 21, 2008 at 04:41:21PM +0100, Thomas Renninger wrote:

> The bug is rather complicated to fix/workaround through the OS (E.g. suspend 
> reordering, AML bug, you simply misread the ACPI spec and it did work for 
> Windows (the ACPI kernel maintainer likes to add the "compatibility" hack, 
> but it's just too intrusive to backport into your stable kernel release you 
> support), ...). But a modification in the DSDT is a one-liner and an obvious 
> fix.
> You desperately search for a flag to be able to make sure you do not risk to 
> break Windows...
> Now they have to ignore the bug. Bad for the vendor, bad for the customer, bad 
> for us (yet another complex "Windows compatibility" hack).

And then later we fix the bug and the Linux workaround starts breaking 
things. The vendor is unhappy. You can't even just key it off kernel 
versions, since distributions will backport arbitrarily large chunks of 
code (and if you doubt this, take a look at the sata tree in the RHEL 
kernel some time). 

> A general Linux flag is the way to start, everything more specific will/can 
> get embedded into this flag later if it makes sense (without any risk for the 
> vendors to break Windows). There are (I expect most) cases where embedding 
> stuff into if(linux) makes a lot sense. But Henrique and others are probably 
> right that we need something more fine grained later (in rare cases, e.g. the 
> in-kernel graphics driver issues).

There's no flag we can provide to indicate a desire for graphics 
POSTing. If vendors want to offer that, then they should provide an 
entry point that triggers it and a kernel driver that calls it. The 
policy for deciding whether or not to do this is far more complex than 
can be provided in-kernel.

-- 
Matthew Garrett | mjg59@srcf.ucam.org