Re: Loading DSDT from initrd, can it be done from grub instead? - Kernel

This is a discussion on Re: Loading DSDT from initrd, can it be done from grub instead? - Kernel ; David Härdeman wrote: > In commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47 the > ACPI_CUSTOM_DSDT_INITRD option was removed. > > I was wondering if it'd be feasible to hack grub to load a custom DSDT > instead (since grub can read filesystems) and then pass ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: Loading DSDT from initrd, can it be done from grub instead?

  1. Re: Loading DSDT from initrd, can it be done from grub instead?

    David Härdeman wrote:
    > In commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47 the
    > ACPI_CUSTOM_DSDT_INITRD option was removed.
    >
    > I was wondering if it'd be feasible to hack grub to load a custom DSDT
    > instead (since grub can read filesystems) and then pass a pointer to a
    > memory location containing the DSDT to the kernel?


    Um, why? What stops you from reverting the offending commit?

    Without further info, I'd assume the feature was removed on policy
    grounds. I.e. it's not nice to be effectively patching the BIOS
    yourself, and vendors have fixed most of their BIOS's / linux is
    slightly more tolerant to broken ones. I don't know whats wrong with
    reading files from the initrd.

    Alan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: Loading DSDT from initrd, can it be done from grub instead?

    Alan Jenkins wrote:

    > David Härdeman wrote:
    >> In commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47 the
    >> ACPI_CUSTOM_DSDT_INITRD option was removed.
    >>
    >> I was wondering if it'd be feasible to hack grub to load a custom DSDT
    >> instead (since grub can read filesystems) and then pass a pointer to a
    >> memory location containing the DSDT to the kernel?

    >
    > Um, why? What stops you from reverting the offending commit?
    >
    > Without further info, I'd assume the feature was removed on policy
    > grounds. I.e. it's not nice to be effectively patching the BIOS
    > yourself, and vendors have fixed most of their BIOS's / linux is
    > slightly more tolerant to broken ones. I don't know whats wrong with
    > reading files from the initrd.



    It was reverted because the code was not really ready and caused some problems.

    >
    > Alan


    Gabriel

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: Loading DSDT from initrd, can it be done from grub instead?

    On Tue, May 20, 2008 13:58, Alan Jenkins wrote:
    > David Härdeman wrote:
    >> In commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47 the
    >> ACPI_CUSTOM_DSDT_INITRD option was removed.
    >>
    >> I was wondering if it'd be feasible to hack grub to load a custom DSDT
    >> instead (since grub can read filesystems) and then pass a pointer to a
    >> memory location containing the DSDT to the kernel?

    >
    > Um, why? What stops you from reverting the offending commit?


    Because doing it from grub (if possible) would allow custom DSDT's to be
    loaded without patching the kernel (e.g. allows distro kernels to be used)
    and without introducing code that opens files from kernel space and mucks
    with both the VFS and ACPI in ugly ways?

    > Without further info, I'd assume the feature was removed on policy
    > grounds. I.e. it's not nice to be effectively patching the BIOS
    > yourself, and vendors have fixed most of their BIOS's / linux is
    > slightly more tolerant to broken ones. I don't know whats wrong with
    > reading files from the initrd.


    If you do not understand the issue at hand, why comment?

    --
    David Härdeman

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: Loading DSDT from initrd, can it be done from grub instead?

    David Härdeman wrote:
    > On Tue, May 20, 2008 13:58, Alan Jenkins wrote:
    >
    >> David Härdeman wrote:
    >>
    >>> In commit 9a9e0d685553af76cb6ae2af93cca4913e7fcd47 the
    >>> ACPI_CUSTOM_DSDT_INITRD option was removed.
    >>>
    >>> I was wondering if it'd be feasible to hack grub to load a custom DSDT
    >>> instead (since grub can read filesystems) and then pass a pointer to a
    >>> memory location containing the DSDT to the kernel?
    >>>

    >> Um, why? What stops you from reverting the offending commit?
    >>

    >
    > Because doing it from grub (if possible) would allow custom DSDT's to be
    > loaded without patching the kernel (e.g. allows distro kernels to be used)
    > and without introducing code that opens files from kernel space and mucks
    > with both the VFS and ACPI in ugly ways?
    >
    >
    >> Without further info, I'd assume the feature was removed on policy
    >> grounds. I.e. it's not nice to be effectively patching the BIOS
    >> yourself, and vendors have fixed most of their BIOS's / linux is
    >> slightly more tolerant to broken ones. I don't know whats wrong with
    >> reading files from the initrd.
    >>

    >
    > If you do not understand the issue at hand, why comment?
    >

    Mea cupla. Apologies if my tone was also inappropriate.

    I saw a short question on an interesting subject, without a context to
    suggest an ongoing
    conversation. I would have saved myself some embarassment if I
    remembered that linux really doesn't like in-kernel filesystem access; I
    just didn't make the connection.

    I guessed wrong, didn't see where you were coming from, and didn't take
    the effort to resolve the SHA commit id. I literally don't have the
    space for a checkout on my main PC and I feel slightly guilty when I hit
    on the gitweb host.

    Ironically, I just looked it up and Google knew what the SHA ID was.
    You might be interested to know that another DH (Dave Hansen) made the
    same suggestion, but using kexec instead of grub to load the DSDT and
    boot kernel.

    Alan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread