Tony,
Some of the IA64 code assumes that ACPI is optional,
and some assumes that it is not.

This makes it possible to try to build with CONFIG_ACPI=n
liked the two attached configs and run into build errors like this:

arch/ia64/kernel/iosapic.c:964: error: `ACPI_INTERRUPT_PMI' undeclared (first use in this function)
arch/ia64/kernel/iosapic.c:964: error: (Each undeclared identifier is reported only once
arch/ia64/kernel/iosapic.c:964: error: for each function it appears in.)
arch/ia64/kernel/iosapic.c:973: error: `ACPI_INTERRUPT_INIT' undeclared (first use in this function)
arch/ia64/kernel/iosapic.c:979: error: `ACPI_INTERRUPT_CPEI' undeclared (first use in this function)

In this case, some header definitions are protected by #if CONFIG_ACPI,
but the code that references them is not.  But at the same time arch/ia64/kernel/acpi.c
which calls the failing routine is obj-y, not obj-$CONFIG_ACPI...

But right behind this build issue is the IA64 PCI code assuming ACPI as well...

How do you want to proceed?
I assume that
1. configs that are theoretically possible, but  would run on nothing, should be discouraged
    as they become maintainer make-work that benefits nobody.
2. littering the code with #ifdef  CONFIG_ACPI should be minimized.

Of the files in arch/ia64/configs/, only sim_defconfig does not include CONFIG_ACPI=y.
If there is a more clever way to disable ACPI on the simulator, perhaps IA64 can always
include CONFIG_ACPI=y and a bunch of #ifdefs can be nuked, and some
annoying build failures can be prevented?

Alternatively, if CONFIG_ACPI is truly optional on IA64, clue me in to exactly where
and why, and maybe we can clean up the build option.

thanks,
-Len