From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: Kbuild and Kconfig Date: Fri, 18 Sep 2015 14:31:50 -0500 Message-ID: <55FC66A6.3020600@cardoe.com> References: <55E736C8.3050302@cardoe.com> <55E83DBE020000780009F3EF@prv-mh.provo.novell.com> <55E85388.3010902@cardoe.com> <55E87CC3020000780009F593@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8952767460904281727==" Return-path: In-Reply-To: <55E87CC3020000780009F593@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: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============8952767460904281727== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GQfuF0JCVQPIjSINxGavxJ0NwX5h7Ipj0" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GQfuF0JCVQPIjSINxGavxJ0NwX5h7Ipj0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/3/15 10:00 AM, Jan Beulich wrote: >>>> On 03.09.15 at 16:04, wrote: >> On 9/3/15 5:31 AM, Jan Beulich wrote: >>>>>> On 02.09.15 at 19:50, wrote: >>>> * target only the xen/ directory tree (i.e. not the toolstack, stubd= oms >>>> or docs) >>> >>> As just said in another reply, allowing for ./configure to pass down >>> options to the configure mechanism in xen/ would seem desirable (as >>> long as configuring in xen/ alone would still work). >> >> My concern would be that the ./configure options would be pretty >> unwieldy. e.g. >> >> ./configure --without-kexec --without-xenlinux --with-schedule=3Dcredi= t2 >> >> You would effectively have to write a script to contain what your >> "distro" (e.g. XenServer, Ubuntu with Xen, Amazon's build) wants. >> However the Linux kernel has a nice way to pass around a defconfig >> and/or .config files to ensure your build always behaves the same. Use= rs >> also have an easy way to see what new options have been added since >> their .config was generated but autoconf does not have that. >=20 > And note that I didn't say this "ordinary" way shouldn't be possible; > in fact I meant it to be the default, with ./configure only allowed to > control things that aren't already set in xen/.config (or whatever > it's going to be named). The idea being that when you say > "--without-" and it affects both parts of the tree, you won't > have to select the option another time in the hypervisor configure > process. >=20 >>>> * split top level config bits to not affect xen/ tree (currently onl= y >>>> XSM_ENABLE / FLASK_ENABLE do) >>> >>> As already said by someone else, this shouldn't be necessary. In fact= >>> I would hope there's (other than debug-build-or-not) no top level >>> setting affecting both tools and hypervisor. >> >> In the case of XSM_ENABLE and FLASK_ENABLE which are at the top level >> they do affect both the tools/ directory and the xen/ directory but in= >> two totally different ways. For the tools side XSM is always enabled n= o >> matter the setting but setting either of those to 'n' results in the >> Flask policy not being built. For the xen/ directory it appears to >> disable XSM support. Hence why I argue that not having top level >> settings would be clearer from a usage standpoint. >=20 > I think where top level setting make sense (like enabling debug builds)= > they should be made work. For existing things at the top level not > really belonging there I agree. >=20 > Jan >=20 Jan, So locally I have in the xen/ (the hypervisor) "make menuconfig" working but I'd likely address any concerns you might have upfront in the patches. Effectively the xen/ directory now when built runs "make defconfig" before it builds to generate the configuration. The default configs I've used match what the tree currently contains. However you expressed interest in having from the top level certain variables controlled from that level like debug. I can pretty easily make it that the effective command line is "make debug=3Dy/1/n/0 defconfig" and that would set CONFIG_DEBUG appropriately. If that's desired I can also include that. Are there other flags that it would be desirable to have them controllable from the top level? --=20 Doug Goldstein --GQfuF0JCVQPIjSINxGavxJ0NwX5h7Ipj0 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 iQJ8BAEBCgBmBQJV/GapXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUFOMP/ihpcwLZdxr7lqeavJKNBX+l X5oS49XqfRlHA8rD/Ht9G+9hX7xzunkPPrTdKwTl08WIrERInbMASH/IVNrcul+N z8Va0nLVxrIllLQxIEUfW4fzJuQe8k9Xn5r/Pht+gkneAzqRjVp23j/DepjGfH+h pdsogR/q8vQVTxQlwmeGzcNBafznFovyadyDse7AojXwZYoEWLYbd+3mKe/BCw5W U0GRXUkGvu2BsBQ8/uJ4tXjF8lNjpsBkBJHX33JvJ5filS4+VPnEW46nc9isBzRi Kq8GvMrTyIWzzycSogsasz/ZbKJCubsKgtCR9unFAh3mVZe8qe+kBbzGmEl8e6Oi wS9CvMtLOPhRqavY8WTtCzCeVWNrZcQmTuRCAsFBj+9UwES9y/Tk4hZko/Pa/kjG WhPE3QQJ6si02jBg+VmBicvphI80DWPAzMO23dywP52eSvrWzn242G6+rb89uwDE OQLfBqn87jcu67Z6cSlPFTvTPCXtRUITd7BPCAQMhPeT15YVHoiFkx6R0C9/+Whu 7Cy3l4hoyMwWyHJbpjmfPif6G+Qvu2s85Jyn9qP5ZTUmH0Lw5Bls2U9fxACDUoqR XUfs097b16rbVnvgjFnqGvolDbdZIIZn6+f/SyvIH/CSPqWHq1k2M9wxt80xm9Qj AFvlXunrk7Lp3J21MgWR =rMnv -----END PGP SIGNATURE----- --GQfuF0JCVQPIjSINxGavxJ0NwX5h7Ipj0-- --===============8952767460904281727== 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 --===============8952767460904281727==--