Am Donnerstag, den 22.09.2005, 00:41 +0530 schrieb Rahul Sundaram:
Ignacio Vazquez-Abrams wrote:
>On Wed, 2005-09-21 at 21:02 +0200, Patrick wrote:
>>Would the powers that be consider including in the next kernel the
>>appropriate patch from
http://gaugusch.at/kernel.shtml which allows you
>>to fix buggy ACPI DSDTs and include them in the initrd so you don't have
>>to recompile the kernel every time you want to make a change? FWIW
>>Mandriva, SuSE and Ubuntu already use them.
>
>http://bugzilla.redhat.com/
>
Might also push for inclusion in upstream kernel
Just FYI: Upstream does not want it AFAIK
http://sourceforge.net/mailarchive/message.php?msg_id=9175150
Quote from Len Brown (ACPI Maintainer):
[...]
Yes, the dsdt-in-initrd patch works.
Yes, it is perfect for the unfortunate but determined soul who
administers a variety of broken machines where they all run the same
kernel and require a different DSDT -- I really do feel sorry for that
person and look forward to the day they find non-broken hardware.
But DSDT overrides are for developers, not end-users, not customers.
Nobody can support the OEM"s firmware, or a modified version of it
except the OEM themselves. If a developer happens to fix an OEM"s
firmware and sends the OEM the fix, that happy situation is purely
between the end-user and the OEM. Distros should absolutely never
be in the business of supporting hardware running modified firmware.
I think that one major Distro pulled the dsdt-in-initrd patch, and I
think it was a mistake for them to do so -- they can"t support it.
That said, it is useful for developers to be able to override the DSDT.
There are two methods -- re-build kernel or re-build kernel and also
modify the initrd.
Kernel re-build is (I think) simple enought. I think the patch at hand
takes it from simple to trivial.
Kernel re-build + initrd update I dislike because it depends on the
existence of an initrd (not everybody uses has an initrd, I haven"t used
an initrd in over a year), and worse, it depends on the format of the
initrd, which we don"t control.
[...]
And no, don't interpret this message as "thl wants the patch merged in
the fedora kernel". I also think we should follow upstream. But maybe
it's time for upstream to rethink the above statement.
CU
thl