|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: some build configuration issues
On Sep 13, 2005, at 5:32 PM, Dan Magenheimer wrote:
Hollis Blanchard <hollisb <at> us.ibm.com> writes:
In xen/drivers/Makefile and xen/Makefile, we need to avoid building
ACPI. More generally, I think it would be a good thing to get away
from
the "ifeq ($(XEN_TARGET_ARCH),foo)" hackery that can be found all over
the Makefiles.
By the way, I retract this statement. There aren't that many
XEN_TARGET_ARCH comparisons in the Makefiles (they're only in the
Makefiles I've looked at :) . Of course, adding PowerPC will increase
this number. Also, there's a fair amount of "#ifdef foo" in C code.
Linux would do it this way:
obj-$(CONFIG_ACPI) += acpi/
Since I don't think we have too many feature permutations to worry
about
in the Xen core, having a per-architecture config.mk would work, e.g.:
CONFIG_ACPI := y
CONFIG_VMX := y
Note that CONFIG_VMX needs to be used in tools/libxc/Makefile, and
CONFIG_ACPI in xen/drivers/Makefile, so this would need to be a
top-level include.
Sounds good to me... for the short-term. I think
the eventual goal is to move drivers/xen to a separate
tree as part of the linux merge effort. I guess then
the contents of config.mk would be merged into the
standard Linux config.
Actually I'm referring to xen/drivers, not linux/drivers/xen.
One question though... if you disable CONFIG_ACPI, you
can't achieve transparent paravirtualization, correct?
On ia64, Xen provides a "pruned" ACPI tree.
In this case, CONFIG_ACPI is not user-configurable. x86* and ia64 would
always define it, and other architectures would never define it.
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|