For the PowerPC merge, one of the issues we''re going to run into is
build
configuration. Currently we have things hacked in the PPC tree, but I think
this is an opportunity to clean up the existing build options.
I started looking at just the xen subdirectory, and found the following
options scattered beneath there:
verbose
debug
perfc
perfc_arrays
crash_debug
ACM_SECURITY
XEN_TARGET_X86_PAE
pae
supervisor_mode_kernel
VALIDATE_VT
All of these are truly optional, in that everything builds just fine no matter
what they are set to. I would like to consolidate these into a single
top-level config file. The Linux configuration style is what I know best, so
following that model we would have a collection of default configurations,
which are copied and then modified to the user''s preference
(I''m thinking
with a text editor, at least for now).
I''m not looking to drag in Linux''s Kbuild system, but a
top-level text file
full of
CONFIG_FOO = y
would be converted into a Make include file and a header file.
Later, I would like to use the same system for non-optional things. For
example, PowerPC would set "CONFIG_ACPI = n", while the other
architectures
would set it to y.
Thoughts? Has anybody else looked at this? Is there anybody in particular who
knows the current build system relatively well?
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 15 Mar 2006, at 17:28, Hollis Blanchard wrote:> > Thoughts? Has anybody else looked at this? Is there anybody in > particular who > knows the current build system relatively well?So far we''ve kept the number of ''user serviceable'' build options very small, preferring to select optional things at run time, and specify non-optional things by hardcoding in asm/config.h. What is it that PPC requires in addition to this? If it''s the ability to more easlly have those config.h hardcodings affect what files get built, then maybe we can pull out those hardcoded CONFIG_ items into a per-arch text file that gets processed into a header file and into a Makefile include. Not so sure about doing that for user-specifiable items, since there are only a small handful. Modifying root Config.mk would be the right place to put user-specific defaults for those I think. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wednesday 15 March 2006 11:44, Keir Fraser wrote:> > So far we''ve kept the number of ''user serviceable'' build options very > small, preferring to select optional things at run time, and specify > non-optional things by hardcoding in asm/config.h. > > What is it that PPC requires in addition to this? If it''s the ability > to more easlly have those config.h hardcodings affect what files get > built, then maybe we can pull out those hardcoded CONFIG_ items into a > per-arch text file that gets processed into a header file and into a > Makefile include.Yup, that''s exactly what it is. While I was looking into that, I noticed that the build options are a little disorganized, and it could be nice to have them all collected in one place. Further, it would clean up some of the existing makefiles. For example: ifeq ($(XEN_TARGET_ARCH),x86_64) LIBDIR = lib64 else LIBDIR = lib endif Instead of that, just "include Config-$(XEN_TARGET_ARCH).mk" and let it set LIBDIR. Now think about ACPI: most archs want it right now, but PPC doesn''t. Rather than have lots of ifeq elif elif ... in xen/drivers/Makefile, it would be far simpler to do: OBJS-$(CONFIG_ACPI) += acpi and let Config-$(XEN_TARGET_ARCH).mk set CONFIG_ACPI or not. -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 15 Mar 2006, at 18:01, Hollis Blanchard wrote:> Now think about ACPI: most archs want it right now, but PPC doesn''t. > Rather > than have lots of ifeq elif elif ... in xen/drivers/Makefile, it would > be far > simpler to do: > OBJS-$(CONFIG_ACPI) += acpi > and let Config-$(XEN_TARGET_ARCH).mk set CONFIG_ACPI or not.Well, let''s start by fixing your current need, which is for the non-optional config parameters, and see how that pans out. Some general cleaning up of the build system would be good and can probably be done by a set of consecutive patches rather than a ''big bang'' approach. For example, I don''t think using GNU make''s wildcards has worked well for working out what files to build, as we end up needing gross patsubst''s to remove the files that are not to be included in the current build. Just explicitly listing the files to build would be better imo. If we could do that and also have Linux-style OBJ-<foo> style then that would be nice. Do you want to cook up some tentative patches? Small increments are good as build systems tend to be fragile beasts, and ours is no exception. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wednesday 15 March 2006 12:18, Keir Fraser wrote:> > For example, I don''t think using GNU make''s wildcards has worked well > for working out what files to build, as we end up needing gross > patsubst''s to remove the files that are not to be included in the > current build. Just explicitly listing the files to build would be > better imo. If we could do that and also have Linux-style OBJ-<foo> > style then that would be nice. > > Do you want to cook up some tentative patches? Small increments are > good as build systems tend to be fragile beasts, and ours is no > exception. :-)Absolutely. I just wanted to make sure this approach made sense to everybody before I started... :) -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hollis Blanchard
2006-Mar-18 01:32 UTC
[Xen-devel] [patch] conditionalize building ACPI (was [RFC] build configuration)
On Wednesday 15 March 2006 12:18, Keir Fraser wrote:> Well, let''s start by fixing your current need, which is for the > non-optional config parameters, and see how that pans out. Some general > cleaning up of the build system would be good and can probably be done > by a set of consecutive patches rather than a ''big bang'' approach.This patch fixes part of my current need: PPC doesn''t want to build ACPI. Two basic problems: one was xen/drivers/Makefile; the other was ALL_OBJS in xen/Rules.mk. While I was setting up ALL_OBJS-y for ACPI, I went ahead and converted the other users, and did the same for CFLAGS (though I really didn''t have to). Note that this patch slightly changes the old behavior of "debug" and "verbose" in CFLAGS: before, if debug=y, verbose=y was set for you. Now you only get what you explicitly enable. Also, perf_array can be used outside of perfc. I don''t consider either of these changes to be problematic, since whoever is building is already changing the config options. Long-term, I think the following are goals to work towards: - Every Makefile should deal only with objects in its own directory and below. ALL_OBJS currently violates this principle: arch/*/Makefile reaches up and does the final link with objects all over the tree. Instead, we can have each arch tell the toplevel Makefile (via arch/*/Rules.mk) how to produce the final image. - Don''t require explicit includes in each Makefile (see drivers/Makefile below). This is possible but takes some thinking; in particular, you wouldn''t recurse into subdirectories, but rather re-invoke make at the top level with a different directory name as an argument. This is just a convenience thing, so not a high priority. - The new drivers/Makefile below does the nice make thing that handles errors and parallel builds properly. This should be expanded to include all other Makefiles (e.g. the "clean" and "$(TARGET)" targets in xen/Makefile). - Object files should be handled in the same way (e.g. OBJ-y). First they''ll need to be explicitly listed, as you noted. I did investigate a few of these, but since I don''t really need them, I started with this patch only. If this works for you, please apply. -- Hollis Blanchard IBM Linux Technology Center Conditionalize building the Xen ACPI driver. Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com> diff -r df0ad1c46f10 xen/Rules.mk --- a/xen/Rules.mk Thu Mar 9 16:03:23 2006 +0100 +++ b/xen/Rules.mk Fri Mar 17 19:05:32 2006 -0600 @@ -33,39 +33,30 @@ OBJS := $(patsubst %.S,%.o,$(S_SRCS)) OBJS := $(patsubst %.S,%.o,$(S_SRCS)) OBJS += $(patsubst %.c,%.o,$(C_SRCS)) -# Note that link order matters! -ALL_OBJS := $(BASEDIR)/common/common.o -ALL_OBJS += $(BASEDIR)/drivers/char/driver.o -ALL_OBJS += $(BASEDIR)/drivers/acpi/driver.o -ifeq ($(ACM_SECURITY),y) -ALL_OBJS += $(BASEDIR)/acm/acm.o -CFLAGS += -DACM_SECURITY -endif -ALL_OBJS += $(BASEDIR)/arch/$(TARGET_ARCH)/arch.o - include $(BASEDIR)/arch/$(TARGET_ARCH)/Rules.mk -CFLAGS += -g -D__XEN__ +# Note that link order matters! +ALL_OBJS-y := $(BASEDIR)/common/common.o +ALL_OBJS-y += $(BASEDIR)/drivers/char/driver.o +ALL_OBJS-$(HAS_ACPI) += $(BASEDIR)/drivers/acpi/driver.o +ALL_OBJS-$(ACM_SECURITY) += $(BASEDIR)/acm/acm.o +ALL_OBJS-y += $(BASEDIR)/arch/$(TARGET_ARCH)/arch.o +ALL_OBJS := $(ALL_OBJS-y) -ifneq ($(debug),y) -CFLAGS += -DNDEBUG -ifeq ($(verbose),y) -CFLAGS += -DVERBOSE -endif -else -CFLAGS += -DVERBOSE -endif +flip_y := n +flip_n := y +flip_ := y +flipyn = $(flip_$(1)) -ifeq ($(crash_debug),y) -CFLAGS += -DCRASH_DEBUG -endif - -ifeq ($(perfc),y) -CFLAGS += -DPERF_COUNTERS -ifeq ($(perfc_arrays),y) -CFLAGS += -DPERF_ARRAYS -endif -endif +__CFLAGS := $(CFLAGS) +CFLAGS-y += -g -D__XEN__ +CFLAGS-$(call flipyn,$(debug)) += -DNDEBUG +CFLAGS-$(ACM_SECURITY) += -DACM_SECURITY +CFLAGS-$(verbose) += -DVERBOSE +CFLAGS-$(crash_debug) += -DCRASH_DEBUG +CFLAGS-$(perfc) += -DPERF_COUNTERS +CFLAGS-$(perfc_arrays) += -DPERF_ARRAYS +CFLAGS := $(__CFLAGS) $(CFLAGS-y) CFLAGS := $(strip $(CFLAGS)) diff -r df0ad1c46f10 xen/arch/ia64/Rules.mk --- a/xen/arch/ia64/Rules.mk Thu Mar 9 16:03:23 2006 +0100 +++ b/xen/arch/ia64/Rules.mk Fri Mar 17 19:05:32 2006 -0600 @@ -1,6 +1,7 @@ ######################################## # ia64-specific definitions +HAS_ACPI := y VALIDATE_VT ?= n ifneq ($(COMPILE_ARCH),$(TARGET_ARCH)) CROSS_COMPILE ?= /usr/local/sp_env/v2.2.5/i686/bin/ia64-unknown-linux- diff -r df0ad1c46f10 xen/arch/x86/Rules.mk --- a/xen/arch/x86/Rules.mk Thu Mar 9 16:03:23 2006 +0100 +++ b/xen/arch/x86/Rules.mk Fri Mar 17 19:05:32 2006 -0600 @@ -1,5 +1,7 @@ ######################################## # x86-specific definitions + +HAS_ACPI := y # # If you change any of these configuration options then you must diff -r df0ad1c46f10 xen/drivers/Makefile --- a/xen/drivers/Makefile Thu Mar 9 16:03:23 2006 +0100 +++ b/xen/drivers/Makefile Fri Mar 17 19:05:32 2006 -0600 @@ -1,8 +1,6 @@ +include $(BASEDIR)/Rules.mk -default: - $(MAKE) -C char - $(MAKE) -C acpi +subdirs-y := char/ +subdirs-$(HAS_ACPI) += acpi/ -clean: - $(MAKE) -C char clean - $(MAKE) -C acpi clean +include $(BASEDIR)/Post.mk diff -r df0ad1c46f10 xen/Post.mk --- /dev/null Thu Jan 1 00:00:00 1970 +0000 +++ b/xen/Post.mk Fri Mar 17 19:05:32 2006 -0600 @@ -0,0 +1,15 @@ + +subdirs-all := $(subdirs-y) $(subdirs-n) + +default: $(subdirs-y) + +.PHONY: FORCE +FORCE: + +%/: FORCE + $(MAKE) -C $* + +clean: $(addprefix _clean_, $(subdirs-all)) +_clean_%/: FORCE + $(MAKE) -C $* clean + _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2006-Mar-18 10:30 UTC
[Xen-devel] Re: [patch] conditionalize building ACPI (was [RFC] build configuration)
On 18 Mar 2006, at 01:32, Hollis Blanchard wrote:> This patch fixes part of my current need: PPC doesn''t want to build > ACPI. Two > basic problems: one was xen/drivers/Makefile; the other was ALL_OBJS in > xen/Rules.mk. > > While I was setting up ALL_OBJS-y for ACPI, I went ahead and converted > the > other users, and did the same for CFLAGS (though I really didn''t have > to). > Note that this patch slightly changes the old behavior of "debug" and > "verbose" in CFLAGS: before, if debug=y, verbose=y was set for you. > Now you > only get what you explicitly enable. Also, perf_array can be used > outside of > perfc. I don''t consider either of these changes to be problematic, > since > whoever is building is already changing the config options.Thanks, looks like the right approach. I''d like to continue down this track but leave any ''big bang'' changes (like no recursive make in subdirectories) until after 3.0.2. I wonder about getting rid of ''verbose'' altogether -- I doubt anyone sets it independently of ''debug'' and people are now used to just setting ''debug=y'' on their build to get all the tracing and assertions we need to help them track down bugs. If there''s no disagreement I''ll make that change. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel