RE: DSDT in initrd

IMHO this patch is very useful because it provides the 
equivalent of a "DSDT module" and avoids building a kernel 
for each DSDT.

This is the 1st reason I've seen for not simply using an ACPI_DSDT_OVERRIDE
config option to pull a DSDT into the kernel from a well-known file name.

I figure that the set of people who go to the trouble to get a custom DSDT
are mostly included in the set of people who config and build a kernel for
their system.  As such, ACPI_DSDT_OVERRIDE would be simple and sufficient --
without requiring admins to change any code.

It makes me uneasy to append the DSDT to the initrd image.  This encumbers
the initrd booting scheme with ACPI BIOS workarounds.  What happens when
somebody changes how initrd works?  If appending a DSDT image to initrd is
okay, why not append other things such as the ACPI black-list, for the same
reasons?

I think I'd be happier with the DSDT being _in_ the initrd as a named
file/module -- just like the other boot-time modules, rather than being
magically appended to the image.  Of course this would require you to run
mkinitrd for each platform; unless multiple named tables were included in
the initrd.

-Len


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com