public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Piel <Eric.Piel@tremplin-utc.net>
To: trenn@suse.de
Cc: "Brown, Len" <len.brown@intel.com>, Greg KH <greg@kroah.com>,
	Adrian Bunk <bunk@stusta.de>, Dave Jones <davej@redhat.com>,
	Zachary Amsden <zach@vmware.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
	Christoph Hellwig <hch@infradead.org>,
	Rusty Russell <rusty@rustcorp.com.au>, Jack Lo <jlo@vmware.com>,
	v4l-dvb-maintainer@linuxtv.org, linux-acpi@vger.kernel.org
Subject: Re: Options depending on STANDALONE
Date: Mon, 07 Aug 2006 20:46:31 +0200	[thread overview]
Message-ID: <44D78A87.3020204@tremplin-utc.net> (raw)
In-Reply-To: <1154972011.4302.712.camel@queen.suse.de>

08/07/2006 07:33 PM, Thomas Renninger wrote/a écrit:
> 
> There are three reasons for the initrd patch (last one also applies for
> the compile in functionality):
Hi, I just happen to be the maintainer "this initrd patch" ;-) I agree 
with you Thomas. IMHO, this patch is really useful in our "not so 
perfect" world. Few more comments below:

> 
> 1)
> There might be "BIOS bugs" that will never get fixed:
> https://bugzilla.novell.com/show_bug.cgi?id=160671
> (Because it's an obvious BIOS bug, "compatibility" fixing it could make
> things worse).
This is really feature #1, PC manufacturers come to sometimes extremely 
ugly things when they code their ACPI tables. You can find lots of BIOS 
containing in their ACPI tables tests like "do this if OS name is 13 
letters long, and that if OS name is 11 letters long..." Obviously 
Linux is most of the time not within those tests!

1.5) Feature adding. Some (crazy?) people are working on new 
implementation of their ACPI table to add features (cf the "Smart 
Battery System for Linux" project).

In those two cases, you really can't expect every user to recompile it's 
Linux kernel to get an new DSDT table :-)

> 2)
> There might be "ACPICA/kernel bugs" that take a while until they get
> fixed:
> 
> This happens often. There comes out a new machine, using AML in a
> slightly other way, we need to fix it in kernel/ACPICA. Until the patch
> appears mainline may take a month or two. Until the distro of your
> choice that makes use of the fix comes out might take half a year or
> more...
> And backporting ACPICA fixes to older kernels is currently not possible
> as ACPICA patches appear in a big bunch of some thousand lines patches.
> But this hopefully changes soon.
> 
> In my mind come:
> - alias broken in certain cases
>    https://bugziall.novell.com/show_bug.cgi?id=113099
> - recon amount of elements in packages
>    https://bugzilla.novell.com/show_bug.cgi?id=189488
> - wrong offsets at Field and Operation Region declarations
>    -> should be compatible for quite a while now
> - ...
Agree, although I  believe of this as more an excuse than a reason. 
Linux is still full of bugs, lots of which cannot be fixed by ACPI table 
swapping anyway...

> 3)
> Debugging.
> This is why at least compile in or via initrd must be provided in
> mainline kernel IMHO. Intel people themselves ask the bug reporter to
> override ACPI tables with a patched table to debug the system.
> Do you really think ripping out all overriding functionality from the
> kernel is a good idea?
Well, I think even Len agree with this usage :-)

All in all, I'm really _not_ asking for inclusion of the patch in the 
main tree. Just asking you not to think too much bad of the distros 
which use this patch ;-) (IIRC, at least Mandriva and Ubuntu include it 
in addition to SuSE)

See you,
Eric


  parent reply	other threads:[~2006-08-07 19:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-03 20:49 Options depending on STANDALONE Brown, Len
2006-08-03 20:51 ` Greg KH
2006-08-03 21:01   ` Dave Jones
2006-08-03 21:41     ` Greg KH
2006-08-07 17:33 ` Thomas Renninger
2006-08-07 17:56   ` Greg KH
2006-08-07 18:46   ` Eric Piel [this message]
2006-08-08 11:00   ` Thomas Renninger
  -- strict thread matches above, loose matches on Subject: below --
2006-08-03 10:14 A proposal - binary Zachary Amsden
2006-08-03 11:16 ` Arjan van de Ven
2006-08-03 18:08   ` Zachary Amsden
2006-08-03 19:03     ` Greg KH
2006-08-03 19:14       ` Zachary Amsden
2006-08-03 19:36         ` Greg KH
2006-08-03 19:56           ` Dave Jones
2006-08-03 20:25             ` Options depending on STANDALONE Adrian Bunk
2006-08-03 20:28               ` Greg KH
2006-08-03 20:41                 ` Dave Jones

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=44D78A87.3020204@tremplin-utc.net \
    --to=eric.piel@tremplin-utc.net \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=bunk@stusta.de \
    --cc=davej@redhat.com \
    --cc=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=jlo@vmware.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@osdl.org \
    --cc=trenn@suse.de \
    --cc=v4l-dvb-maintainer@linuxtv.org \
    --cc=zach@vmware.com \
    /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