RE: Options depending on STANDALONE
From: Thomas Renninger
Date: Mon Aug 07 2006 - 13:27:42 EST
On Thu, 2006-08-03 at 16:49 -0400, Brown, Len wrote:
> >On Thu, Aug 03, 2006 at 10:25:43PM +0200, Adrian Bunk wrote:
> >> ACPI_CUSTOM_DSDT seems to be the most interesting case.
> >> It's anyway not usable for distribution kernels, and AFAIR the ACPI
> >> people prefer to get the kernel working with all original DSDTs
> >> (which usually work with at least one other OS) than letting
> >> the people workaround the problem by using a custom DSDT.
> >Not true at all. For SuSE kernels, we have a patch that lets people
> >load a new DSDT from initramfs due to broken machines requiring a
> >replacement in order to work properly.
> CONFIG_ACPI_CUSTOM_DSDT allows hackers to debug their system
> by building a modified DSDT into the kernel to over-ride what
> came with the system. It would make no sense for a distro
> to use it, unless the distro were shipping only on 1 model machine.
> This technique is necessary for debugging, but makes no
> sense for production.
> The initramfs method shipped by SuSE is more flexible, allowing
> the hacker to stick the DSDT image in the initrd and use it
> without re-compiling the kernel.
> I have refused to accept the initrd patch into Linux many times,
> and always will.
> I've advised SuSE many times that they should not be shipping it,
> as it means that their supported OS is running on modified firmware --
> which, by definition, they can not support.
Tainting the kernel if done so should be sufficient.
> Indeed, one could view
> this method as couter-productive to the evolution of Linux --
> since it is our stated goal to run on the same machines that Windows
> runs on -- without requiring customers to modify those machines
> to run Linux.
There are three reasons for the initrd patch (last one also applies for
the compile in functionality):
There might be "BIOS bugs" that will never get fixed:
(Because it's an obvious BIOS bug, "compatibility" fixing it could make
There might be "ACPICA/kernel bugs" that take a while until they get
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
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
- recon amount of elements in packages
- wrong offsets at Field and Operation Region declarations
-> should be compatible for quite a while now
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?
It is true that some users are happy with a fixed DSDT, even you tell
them to find the root cause..., but sooner or later they always come
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/