All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Doug Goldstein <cardoe@cardoe.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Keir Fraser <keir@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCHv6] 02/28] build: build Kconfig and config rules
Date: Mon, 30 Nov 2015 07:36:15 -0700	[thread overview]
Message-ID: <565C6CEF02000078000BA42E@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1448387538-12208-3-git-send-email-cardoe@cardoe.com>

>>> On 24.11.15 at 18:51, <cardoe@cardoe.com> wrote:
> --- a/.gitignore
> +++ b/.gitignore
> @@ -217,6 +217,11 @@ tools/xentrace/tbctl
>  tools/xentrace/xenctx
>  tools/xentrace/xentrace
>  xen/.banner
> +xen/.config
> +xen/.config.old
> +xen/defconfig
> +xen/**/*.cmd
> +xen/**/modules.order

The last two seem rather dubious to me in our environment.

> @@ -239,6 +244,9 @@ xen/include/headers++.chk
>  xen/include/asm
>  xen/include/asm-*/asm-offsets.h
>  xen/include/compat/*
> +xen/include/config.h

Linux doesn't seem to generate a file like this. Is this perhaps a
stale entry you're copying over?

> --- /dev/null
> +++ b/xen/Kconfig
> @@ -0,0 +1,26 @@
> +#
> +# For a description of the syntax of this configuration file,
> +# see Documentation/kbuild/kconfig-language.txt from the Linux

This path needs fixing.

> +# kernel source tree.
> +#
> +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration"
> +
> +config SRCARCH
> +	string
> +	option env="SRCARCH"
> +
> +config ARCH
> +	string
> +	option env="ARCH"
> +
> +source "arch/$SRCARCH/Kconfig"
> +
> +config XEN_FULLVERSION
> +	string
> +	option env="XEN_FULLVERSION"
> +
> +config DEFCONFIG_LIST
> +	string
> +	option defconfig_list
> +	default "$ARCH_DEFCONFIG"
> +	default "arch/$SRCARCH/defconfig"

Linux'es variant has just SRCARCH and the source directive. Why
do we need so much more here? In any even I again think you
should at least briefly explain any extensions you do in the commit
message.

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/..
>  
>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
>  
> +# Don't break if the build process wasn't called from the top level
> +XEN_TARGET_ARCH ?= $(shell uname -m)

I don't see the need for this. We already require setting this on the
command line when invoking a build process bypassing the top level
directory. Later in the series, when actually using the produced
xen/.config, I could see this becoming a nice enhancement (by
reading the value from the file).

> @@ -216,3 +220,16 @@ FORCE:
>  
>  %/: FORCE
>  	$(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o
> +
> +kconfig := silentoldconfig oldconfig config menuconfig defconfig \
> +	nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig
> +.PHONY: $(kconfig)
> +$(kconfig):
> +	$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) $@
> +
> +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd
> +	$(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) silentoldconfig

Okay, I have found the Linux original to this and it's the same there,
but I'd like to ask anyway: How can this work without $* getting
passed on?

> +# Allow people to just run `make` as before and not force them to configure
> +$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ;
> +	$(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) defconfig

Is this correct? If I have xen/.config but no
xen/include/config/auto.conf.cmd I surely don't want "defconfig" to
be run (unless "defconfig" honors xen/.config, in which case the
goal's name would be questionable)?

Also do you really need all the explicit $(BASEDIR) references in the
rules above?

> --- /dev/null
> +++ b/xen/arch/arm/configs/arm32_defconfig
> @@ -0,0 +1 @@
> +CONFIG_64BIT=n
> diff --git a/xen/arch/arm/configs/arm64_defconfig 
> b/xen/arch/arm/configs/arm64_defconfig
> new file mode 100644
> index 0000000..e69de29

As said before I'm not really up to speed with defconfigs, but the
arm64 variant being empty but the arm32 one disabling 64BIT
seems backwards: You don't even have a choice on arm32.

> --- /dev/null
> +++ b/xen/arch/x86/Kconfig
> @@ -0,0 +1,18 @@
> +config X86_64
> +	def_bool y
> +
> +config X86
> +	def_bool y
> +	select HAS_GDBSX

Didn't you mean to convert HAS_* in subsequent patches?

Also - not 64BIT here, yet this - if added to ARM - should be added
here too so it can be used in common code.

> +config ARCH_DEFCONFIG
> +	string
> +	default "arch/x86/configs/x86_64_defconfig"

x86_defconfig perhaps?

> --- /dev/null
> +++ b/xen/scripts/kconfig/Makefile
> @@ -0,0 +1,77 @@
> +# xen/scripts/kconfig
> +
> +MAKEFLAGS += -rR

Why?

> +# default rule to do nothing
> +all:
> +
> +XEN_ROOT = $(CURDIR)/..
> +
> +# Xen doesn't have a silent build flag
> +quiet := silent_
> +Q := @
> +kecho := :
> +
> +# eventually you'll want to do out of tree builds
> +srctree = $(XEN_ROOT)/xen
> +objtree = $(srctree)
> +src := scripts/kconfig
> +obj := $(src)
> +KBUILD_SRC :=
> +
> +# handle functions (most of these lifted from different Linux makefiles
> +dot-target = $(dir $@).$(notdir $@)
> +depfile = $(subst $(comma),,$(dot-target).d)
> +basetarget = $(basename $(notdir $@))
> +cmd = $(cmd_$(1))
> +if_changed = $(if y, \
> +	@set -e; \
> +	$(cmd_$(1)); \
> +	)
> +
> +if_changed_dep = $(if y, \
> +	@set -e;	\
> +	$(cmd_$(1)); \
> +	)

Considering how much you stripped these fro their Linux original, why
did you leave the always true $(if ...) in here, and why did you not
consolidate things only single lines (helping readability).

> +define multi_depend
> +$(foreach m, $(notdir $1), \
> +	$(eval $(obj)/$m: \
> +	$(addprefix $(obj)/, $(foreach s, $3, $($(m:%$(strip $2)=%$(s)))))))
> +endef

Do you really need this?

> +# Set our default defconfig file
> +KBUILD_DEFCONFIG := $(ARCH)_defconfig
> +
> +# provide our shell
> +CONFIG_SHELL := $(SHELL)
> +
> +# provide the host compiler
> +HOSTCC := gcc
> +HOSTCXX := g++

Why is the C setting from ./Config.mk not good enough (the C++
one should then be added there if indeed needed, which I doubt)?

Jan

  reply	other threads:[~2015-11-30 14:36 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24 17:51 [PATCHv6] 00/28] Kconfig conversion Doug Goldstein
2015-11-24 17:51 ` [PATCHv6] 01/28] build: import Kbuild/Kconfig from Linux 4.2 Doug Goldstein
2015-11-30 13:59   ` Jan Beulich
2015-11-30 15:34     ` Doug Goldstein
2015-11-30 15:42       ` Ian Jackson
2015-11-30 17:03         ` Jan Beulich
2015-11-30 17:16           ` Ian Jackson
2015-11-30 17:21             ` Ian Campbell
2015-12-01 11:00             ` Jan Beulich
2015-12-02 10:39               ` Ian Campbell
2015-12-03 16:04                 ` Doug Goldstein
2015-11-30 15:55       ` Jan Beulich
2015-11-30 17:00         ` Doug Goldstein
2015-11-30 17:04           ` Ian Jackson
2015-11-30 17:10             ` Doug Goldstein
2015-11-30 17:19           ` Ian Campbell
2015-12-01 20:04             ` Doug Goldstein
2015-12-02  9:38               ` Jan Beulich
2015-12-02 14:34                 ` Doug Goldstein
2015-12-02  9:47               ` Ian Campbell
2015-12-02 14:33                 ` Doug Goldstein
2015-12-01 11:01           ` Jan Beulich
2015-11-24 17:51 ` [PATCHv6] 02/28] build: build Kconfig and config rules Doug Goldstein
2015-11-30 14:36   ` Jan Beulich [this message]
2015-11-30 17:53     ` Doug Goldstein
2015-12-01 11:22       ` Jan Beulich
2015-12-03  0:34         ` Doug Goldstein
2015-12-03  8:57           ` Jan Beulich
2015-12-07 21:27             ` Doug Goldstein
2015-12-08  7:32               ` Jan Beulich
2015-12-08 14:16                 ` Doug Goldstein
2015-12-08 14:25                   ` Jan Beulich
2015-12-08 17:59                     ` Doug Goldstein
2015-12-08 18:04                       ` Andrew Cooper
2015-12-09 10:13                         ` Ian Campbell
2015-11-24 17:51 ` [PATCHv6] 03/28] build: use generated Kconfig options for Xen Doug Goldstein
2015-11-30 14:45   ` Jan Beulich
2015-12-08 19:53     ` Doug Goldstein
2015-12-09  8:40       ` Jan Beulich
2015-12-09 20:34         ` Doug Goldstein
2015-12-09 20:53           ` Doug Goldstein
2015-12-10 11:45             ` Jan Beulich
2015-12-10 11:43           ` Jan Beulich
2015-11-24 17:51 ` [PATCHv6] 04/28] build: convert HAS_PASSTHROUGH use to Kconfig Doug Goldstein
2015-11-30 14:50   ` Jan Beulich
2015-12-03  0:36     ` Doug Goldstein
2015-12-03  8:58       ` Jan Beulich
2015-11-24 17:51 ` [PATCHv6] 05/28] build: convert HAS_DEVICE_TREE " Doug Goldstein
2015-11-24 17:51 ` [PATCHv6] 06/28] build: convert HAS_PCI " Doug Goldstein
2015-11-24 17:51 ` [PATCHv6] 07/28] build: convert HAS_NS16550 " Doug Goldstein
2015-11-30 14:55   ` Jan Beulich
2015-11-24 17:51 ` [PATCHv6] 08/28] build: convert HAS_IOPORTS " Doug Goldstein
2015-11-30 14:56   ` Jan Beulich
2015-11-30 15:01     ` Jan Beulich
2015-12-03  0:39       ` Doug Goldstein
2015-12-03  9:06         ` Jan Beulich
2015-11-24 17:51 ` [PATCHv6] 09/28] build: convert HAS_ACPI " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 10/28] build: convert HAS_VIDEO " Doug Goldstein
2015-11-30 15:03   ` Jan Beulich
2015-11-24 17:52 ` [PATCHv6] 11/28] build: convert HAS_VGA " Doug Goldstein
2015-11-30 15:04   ` Jan Beulich
2015-11-24 17:52 ` [PATCHv6] 12/28] build: convert HAS_CPUFREQ " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 13/28] build: convert HAS_GDBSX " Doug Goldstein
2015-11-30 15:06   ` Jan Beulich
2015-11-24 17:52 ` [PATCHv6] 14/28] build: convert HAS_PDX " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 15/28] build: convert HAS_KEXEC " Doug Goldstein
2015-11-30 15:10   ` Jan Beulich
2015-11-24 17:52 ` [PATCHv6] 16/28] build: convert HAS_ARM_HDLCD " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 17/28] build: convert HAS_CADENCE_UART " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 18/28] build: convert HAS_PL011 " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 19/28] build: convert HAS_EXYNOS4210 " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 20/28] build: convert HAS_OMAP " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 21/28] build: convert HAS_SCIF " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 22/28] build: convert HAS_EHCI " Doug Goldstein
2015-11-30 15:13   ` Jan Beulich
2015-11-24 17:52 ` [PATCHv6] 23/28] build: convert HAS_MEM_ACCESS " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 24/28] build: convert HAS_MEM_PAGING " Doug Goldstein
2015-11-30 15:16   ` Jan Beulich
2015-11-24 17:52 ` [PATCHv6] 25/28] build: convert HAS_MEM_SHARING " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 26/28] build: convert HAS_GICV3 " Doug Goldstein
2015-11-24 17:52 ` [PATCHv6] 27/28] build: convert CONFIG_COMPAT " Doug Goldstein
2015-11-30 15:18   ` Jan Beulich
2015-12-03 12:52     ` Doug Goldstein
2015-12-03 12:54       ` Jan Beulich
2015-11-24 17:52 ` [PATCHv6] 28/28] build: convert kexec options to CONFIG_KEXEC Doug Goldstein
2015-11-30 15:51 ` [PATCHv6] 00/28] Kconfig conversion Julien Grall
2015-11-30 17:05   ` Doug Goldstein
2015-11-30 17:13     ` Julien Grall
2015-12-03  3:02 ` Doug Goldstein
2015-12-03  8:29   ` Jan Beulich
2015-12-03  9:50     ` Ian Campbell
2015-12-03 11:00       ` Jan Beulich
2015-12-03 11:10         ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=565C6CEF02000078000BA42E@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=ian.campbell@citrix.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.