From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [PATCHv6] 02/28] build: build Kconfig and config rules Date: Mon, 7 Dec 2015 15:27:40 -0600 Message-ID: <5665F9CC.60408@cardoe.com> References: <1448387538-12208-1-git-send-email-cardoe@cardoe.com> <1448387538-12208-3-git-send-email-cardoe@cardoe.com> <565C6CEF02000078000BA42E@prv-mh.provo.novell.com> <565C8D06.4080907@cardoe.com> <565D90FE02000078000BAA7C@prv-mh.provo.novell.com> <565F8E25.6070008@cardoe.com> <566011FB02000078000BB930@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2852134487783166938==" Return-path: In-Reply-To: <566011FB02000078000BB930@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , Keir Fraser , Stefano Stabellini , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============2852134487783166938== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="v8429VCis6fdukxanLGqJaAVMfifIDT4g" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --v8429VCis6fdukxanLGqJaAVMfifIDT4g Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/3/15 2:57 AM, Jan Beulich wrote: >>>> On 03.12.15 at 01:34, wrote: >> On 12/1/15 5:22 AM, Jan Beulich wrote: >>>>>> On 30.11.15 at 18:53, wrote: >>>> On 11/30/15 8:36 AM, Jan Beulich wrote: >>>>>>>> On 24.11.15 at 18:51, wrote: >>>>>> +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration" >>>>>> + >>>>>> +config SRCARCH >>>>>> + string >>>>>> + option env=3D"SRCARCH" >>>>>> + >>>>>> +config ARCH >>>>>> + string >>>>>> + option env=3D"ARCH" >>>>>> + >>>>>> +source "arch/$SRCARCH/Kconfig" >>>>>> + >>>>>> +config XEN_FULLVERSION >>>>>> + string >>>>>> + option env=3D"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. >>>> >>>> I'm not understanding the question here. Linux has 5 items in their >>>> list. The last two are identical to the 2 that I retained. Given oth= er >>>> evolutions of the patchset I can drop the last one and keep it as ju= st >>>> $ARCH_DEFCONFIG since I've always got that defined for arm and x86. >>> >>> Oh, the context was ambiguous: The comment related to everything >>> quoted, not just the last option. I.e. I'm being irritated by there b= eing >>> quite a few more config options here compared to Linux. >> >> So all these items are in Linux. And they seem to actually be necessar= y. >> You'll just find them in different files (e.g. init/Kconfig) that I >> didn't import because we really didn't need them for anything. >=20 > Okay, this makes sense. Remains the question on the > XEN_FULLVERSION name: Doesn't this collide with the identically > named make variable? Or is it intentionally named the same? In > which case - what's the purpose? There's no > CONFIG_KERNELVERSION resulting from this in Linux (which seems > in line with documentation). This is intentional. Its for when you run "make {menu,n,g,x}config" and it'll show the version info at the top. It also puts the version info as a comment inside the .config. Just cosmetic stuff. >=20 >>>>>> --- a/xen/Makefile >>>>>> +++ b/xen/Makefile >>>>>> @@ -17,6 +17,9 @@ export XEN_ROOT :=3D $(BASEDIR)/.. >>>>>> =20 >>>>>> EFI_MOUNTPOINT ?=3D $(BOOT_DIR)/efi >>>>>> =20 >>>>>> +# Don't break if the build process wasn't called from the top lev= el >>>>>> +XEN_TARGET_ARCH ?=3D $(shell uname -m) >>>>> >>>>> I don't see the need for this. We already require setting this on t= he >>>>> 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). >>>> >>>> One of the early on reviews told me it was not required (and I can >>>> confirm that I can run "git clean -xdf && cd xen && make" and it wil= l >>>> build). This change makes that behavior still work. >>> >>> Yes, non-cross builds of course have been working without setting >>> that variable. I was (not clearly enough) referring to cross builds, >>> including hypervisor builds on ix86 distros (which I consider at best= >>> kind of cross, but would really deem to be native with there not >>> being any 32-bit hypervisor anymore). >>> >>> So can you clarify what exactly breaks in which way without this >>> change? >> >> The ability to "git clone git://xen && cd xen/xen && make" because I >> couldn't pick the correct defconfig to use. See the rules just below >> this reply in xen/Makefile where they are used. >=20 > Okay. But - does "uname -m" really produce e.g. "arm32" and "arm64" > respectively, and not, as I would expect, "armv..." and "aarch64"? > See the setup of XEN_COMPILE_ARCH in ./Config.mk. I've switched to pulling in Config.mk >=20 >>>>>> @@ -216,3 +220,16 @@ FORCE: >>>>>> =20 >>>>>> %/: FORCE >>>>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o >>>>>> + >>>>>> +kconfig :=3D silentoldconfig oldconfig config menuconfig defconfi= g \ >>>>>> + nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig= >>>>>> +.PHONY: $(kconfig) >>>>>> +$(kconfig): >>>>>> + $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=3D$(XEN_TARG= ET_ARCH) $@ >>>>>> + >>>>>> +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.= conf.cmd >>>>>> + $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=3D$(XEN_= TARGET_ARCH) silentoldconfig >>>>> >>>>> Okay, I have found the Linux original to this and it's the same the= re, >>>>> but I'd like to ask anyway: How can this work without $* getting >>>>> passed on? >>>> >>>> silentoldconfig is the step that actually takes the .config and >>>> generates out all the files like auto.conf and generated/config.h It= >>>> should be in xen/scripts/kconfig/Makefile.linux I believe. >>> >>> Not sure what you're trying to tell me, but in any event I don't see >>> this to answer the question. >> >> So maybe I'm not understanding your question. I don't understand why $= * >> would need to be passed on. The target "silentoldconfig" in the kconfi= g >> Makefile takes care of building all of the files that the rule could >> match. That's what I tried to say in my original response. I believe >> your point is that I would have to pass the target file on like the >> below implicit case? >=20 > Yes, that's what one would expect from a pattern rule. And yes, now > I understand your answer to the original question. >=20 >>>>>> +config ARCH_DEFCONFIG >>>>>> + string >>>>>> + default "arch/x86/configs/x86_64_defconfig" >>>>> >>>>> x86_defconfig perhaps? >>>> >>>> No. I was told to drop support for x86 entirely in an earlier review= =2E >>>> Its not possible to configure for 32-bit x86 in v6. >>> >>> x86 !=3D 32-bit. I think you're mixing this up with ix86 or x86-32. >>> Here I consider x86 as to basic architecture without any >>> particular bit width in mind. >> >> ok. Well the syntax is still "arch/SUBARCH/configs/ARCH_defconfig" so >> the original is correct. There is no defconfig for the ambiguous x86 >> family. You're either building for x86_64 or x86_32 (which I referred = to >> as x86 in my original response). >> >> This defconfig is for the 64-bit architecture of x86 (x86_64) and ther= e >> for its named correctly. >=20 > But there is no x86_32 architecture form the hypervisor build's > point of view, and hence x86 isn't ambiguous. In fact the mid-term > plan is to remove leftovers of references to x86_64 (like the > arch/x86/x86_64/ or include/asm-x86/x86_64/ directories) where > possible. The only place they need to be kept are in the public > interface. That's fine but you don't build things for "x86". You build them for "x86_64". XEN_TARGET_ARCH takes in "x86_64". >=20 >>>>>> +# Set our default defconfig file >>>>>> +KBUILD_DEFCONFIG :=3D $(ARCH)_defconfig >>>>>> + >>>>>> +# provide our shell >>>>>> +CONFIG_SHELL :=3D $(SHELL) >>>>>> + >>>>>> +# provide the host compiler >>>>>> +HOSTCC :=3D gcc >>>>>> +HOSTCXX :=3D 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)? >>>> >>>> From an earlier review I dropped the usage of Config.mk because I wa= s >>>> told the hypervisor (xen/) should build without ./configure being ru= n. >>>> The C++ is needed for the kconfig frontends. >>> >>> But Config.mk has nothing to do with top level configure, and is e.g.= >>> being included from xen/Rules.mk. >> >> I'm not including Config.mk in those build files because it includes a= >> lot and many of them are redefinitions of what kconfig does. All I wou= ld >> get out of it would be HOSTCC. >> >> $ wc -l config/x86_64.mk config/Linux.mk config/StdGNU.mk Config.mk >> 32 config/x86_64.mk >> 3 config/Linux.mk >> 50 config/StdGNU.mk >> 287 Config.mk >> 372 total >> >> If there was a bit more granularity (config/host.mk) it wouldn't be so= bad. >=20 > Indeed introducing that would seem like a useful intermediate step. > No multiple points of defining the same thing please (because of > someone actually needing to fiddle with them will quite likely touch > only one instance, resulting in time wasted figuring out why things > no longer work uniformly). >=20 > Jan >=20 I can submit that outside of this series before the next repost. --=20 Doug Goldstein --v8429VCis6fdukxanLGqJaAVMfifIDT4g Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWZfnPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUsCAP/2exgPiYAHi4nm7zh/+K/6/v 5V0KKBy7fdddtpuHL79pX1m3yyNwa/237gHTSIiONyFcrlrFvBeCjJCaTb97pm08 Ddy2/voCTHsRjur8azQ2uBr+A1GKHGqeuiCWcsC8OSBjR4nuRIKV/OxpWqYMaZf+ tsGdZjDPU6FoIYcIYQBrFG6Bl47zQ1TazOcw0M8icL6Oo6Gd+tc/qZfp2yTqSlMm R8bF1L5F4srsh6ID2/xlYU93dNeW0KZjmVkz0Mn5fLIg2XNJkg3fewSUnhCWFuLB IyOmNAJQWyJMLIHWN5zmJINKRVY6ayEhK8lK5DcoUKhmgEUPzrx+bRKQaDkrE7vU cwXIOxi2x4IJtd1LLORJ2kg3mKPdFqDax5yATcR/c6ZTAzmpypMccaxzFpn1uZhG ZFFQiS8dxJ4uDNqZBM+vr2mXJMXo+DeHAd5kqmEXrOjUi2fzJ4obMMIEt1azuOO1 49zn5KkzI8yytP5fvbIS/Zmp85vLSNAqXGX6RhPYvIoIUn7eHqf2LOs8OX1xCLNN jyN+BFa13H4fdJ4hb+lmI3VTDxiyJ8+mzrObl4EERaxA4OHKT9DlxhNfVb6UcZeG jgOWBzmPLLZh4CUZzMnDyB7u2scgUe5zBbJsDYDi6NrtEbNWR+SVqgS8+agnORvy 6X/Mg88x+ygqFoPZjnSW =lqR6 -----END PGP SIGNATURE----- --v8429VCis6fdukxanLGqJaAVMfifIDT4g-- --===============2852134487783166938== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2852134487783166938==--