From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [RFC 00/29] Incomplete Kconfig conversion Date: Tue, 6 Oct 2015 10:58:10 -0500 Message-ID: <5613EF92.50601@cardoe.com> References: <1444082620-3253-1-git-send-email-cardoe@cardoe.com> <1444136748.5302.160.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5480897615954328324==" Return-path: In-Reply-To: <1444136748.5302.160.camel@citrix.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: 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) --===============5480897615954328324== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t1mURIWT5R7oLAt7hdLXImBGpBo8g4BjB" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t1mURIWT5R7oLAt7hdLXImBGpBo8g4BjB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/6/15 8:05 AM, Ian Campbell wrote: > On Mon, 2015-10-05 at 17:03 -0500, Doug Goldstein wrote: >> Ultimately my goal is to allow for more parts of the hypervisor to be = turned >> off at compile time and potentially make it easier to include more >> experimental features by others which can be turned off by default. Al= so to >> provide the one true location for all possible knobs in the source cod= e. >=20 > I'm OK with the switch to Kconfig generally but I'd like us to start wi= th a > conversion which offers the exact same set of options as exist today in= the > Makefile (i.e. not very many at all) and where the use of select and et= c > means that anyone who asks Kconfig to generate the default config (i.e.= not > an explicit defconfig file) will produce a binary with the exact same > feature set as today. (Sorry if I misunderstood whether that is the goa= l > with this initial series vs. your ultimate goal) >=20 > IOW we start by treating Kconfig as a better way for _developers_ to > control the configuration of Xen at compile time than adding and removi= ng > #defines (i.e. the one true location thing you mention) but not (yet) a= s a > way to let users produce a wide variety of different images. >=20 > Then we can start to consider patches which make options available for > users, on a case by case basis. >=20 > Maybe those options should be behind some sort of dependency gate which= > means that explicit action is needed in order to deviating from the > defaults such that it is acknowledged by the user that they have done s= o > and that such configurations may not even build let alone work. >=20 > I'd also like to propose that we consider having a strict requirement f= or > patches to the test infrastructure to exercise any new user-facing opti= on > before we accept the patch implementing it. >=20 > What I don't want to see is fragmentation where every distro does somet= hing > subtly different or normal users ending up with different configuration= s to > the norm. By "normal users" I mean those without specialised requiremen= ts > or environments who aren't willing/able to support their decision to st= ep > off the beaten path. >=20 > Ian. >=20 Ian, You stated this better than I did. My goal is not to necessarily make this like the Linux kernel where users toggle on different bits at a whim but more for developers and companies shipping Xen, basically those with specialized environments could use this to upstream more code and have it disabled by default. The current patchset only exposes KEXEC as a user facing option because its currently a user facing option in the source tree. I would not expand the list of user facing options past that. I consider adding more outside of the scope of this work and something that would happen after this series lands on a case by case basis. My ultimate goal with this initial work is to get all the developer knobs in one place because currently they are spread around as Makefile defines or defines in a header file and get a little bit of code comments around them. --=20 Doug Goldstein --t1mURIWT5R7oLAt7hdLXImBGpBo8g4BjB 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 iQJ8BAEBCgBmBQJWE++SXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUCiUQAJg8YQdY6N3AXCP3rSzTdgBQ EqCF7VeY7L2dKVgK9yH6fQTFuDK3VxRRvyOgkh0RK8wBW52MXpJQ+8G/lHN/bpbg xOAsEJuJKaglWaLIjJ20F8v/JyHOpelHx1TXT3S5E63hUnJNYTp14Ksba3HP1/sd HXznwj7NYPRt7TV2OIxGdzOBaXTtrI5cpL2eyaJQrX4GvYSUmg9k9WxypEL3n368 1UlOrmsYtAfRuoHOS+i7Qomn0pqlGPN02hJ7IiRjR7ovE6TcOHlEKyjSYmOJDgOT TxLHkc/mIcrRSeozMUHR6Wk32mwMvfMlH53ShgUYA6ynUeDQ4OmBbeWiCvh8i7SC 9jznyZAqQyPHRKP2XflgiK/wsXbyFL9wTQJnj2mNpwb7u+FD046XbWovoeexWLTw Aoi+C3hXId4FUd6uaCa2z5TDDA3eGH1VqxwPxs7hEV7rvg0cN3xPIKhoXt3Ee0lr p8oFMpgePQg/FDW7R4xKvl8+OMGq2cdDmXUI4M+a2TYy9S+HhcV3KrpWnz2aQf/I FM71j9LzKe6VtLK5gCUl/DxOSqXLeRit0m4KbZWWqFrC1aUa1r4NiItnwW7o5Avj hai1UWZQztel8Ba4T+ojHp9NmSvzOsRvooVjIaTXWFamXVkGrNEY+Bm0OzDLrFxd u1c1luylsdMPUEKKVSTX =9pvb -----END PGP SIGNATURE----- --t1mURIWT5R7oLAt7hdLXImBGpBo8g4BjB-- --===============5480897615954328324== 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 --===============5480897615954328324==--