I'm looking into building the various tools and libraries for PPC now,
and it's exposing a bit of build configuration difficulty. Here are some
specific issues:
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. 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.
(As a side benefit, the "obj-$(CONFIG_FOO) += ..." thing could solve the
current parallel-hostile Makefile code like this from
xen/drivers/Makefile:
default:
$(MAKE) -C char
$(MAKE) -C acpi
)
Another problem is that PPC needs to have a different CC for tools/ than
for xen/. There are library dependencies like zlib in tools/, and there
is no guarantee or need to have a 64-bit zlib installed. Accordingly,
the PPC arch-config.mk could specify a 32-bit TOOLS_CC and 64-bit CC.
Looking at the VMX case a little more, we can see that xc_vmx_build() is
called from tools/python/xen/lowlevel/xc/xc.c. That will probably need
an ifdef, especially since pyxc_vmx_build() is listed in the large
static pyxc_methods list. That means in addition to arch-config.mk, we
will need a top-level config.h for C code to use, including some of the
same information (such as CONFIG_VMX).
In general though, I think such ifdefs should be avoided, which
typically means calling out to arch-specific code (or building an
arch-specific file).
Thoughts?
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home