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 -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list