Re: [Xen-devel] Re: some build configuration issues

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

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