[lkml]   [2006]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: Options depending on STANDALONE
    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
    things worse).

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-08-07 19:33    [W:0.024 / U:2.648 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site