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@lists.xensource.com http://lists.xensource.com/xen-devel
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. 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. One question though... if you disable CONFIG_ACPI, you can''t achieve transparent paravirtualization, correct? On ia64, Xen provides a "pruned" ACPI tree. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 wouldPost 3.0, a spring clean of all of the Makefiles would be a very good thing. Right now isn''t the time to do any major surgery. [Our record with "minor" Makefile changes sucks - there have almost always been unintended side effects with Makefile patches]> (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 acpiI worry less about the lack of opportunities for make parallelism as Xen builds fast anyhow. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sep 14, 2005, at 7:03 AM, Ian Pratt wrote:>> 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 > > Post 3.0, a spring clean of all of the Makefiles would be a very good > thing. Right now isn''t the time to do any major surgery. [Our record > with "minor" Makefile changes sucks - there have almost always been > unintended side effects with Makefile patches]No argument here; I don''t think anybody is intending for PowerPC code to go into 3.0 anyways. Since I need to work on this now though, I''d like to know that the solution is generally acceptable... -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hollis Blanchard
2005-Sep-14 14:51 UTC
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@lists.xensource.com http://lists.xensource.com/xen-devel
Magenheimer, Dan (HP Labs Fort Collins)
2005-Sep-14 16:01 UTC
RE: [Xen-devel] Re: some build configuration issues
> Actually I''m referring to xen/drivers, not linux/drivers/xen.Oops, sorry, I misunderstood the first line in your original post:>I''m looking into building the various tools and libraries for PPC now,which made me think you were talking about xenlinux. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel