[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Include DSDT initrd patch?



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]