From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: Kbuild and Kconfig Date: Thu, 3 Sep 2015 08:58:05 -0500 Message-ID: <55E851ED.5010305@cardoe.com> References: <55E736C8.3050302@cardoe.com> <55E74014.7010500@citrix.com> <1441274169.26292.323.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8201466249894260752==" Return-path: In-Reply-To: <1441274169.26292.323.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 , Andrew Cooper , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============8201466249894260752== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hLe3KOuvlB1DAETFw1abQcxNVIUMQPlka" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hLe3KOuvlB1DAETFw1abQcxNVIUMQPlka Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/3/15 4:56 AM, Ian Campbell wrote: > On Wed, 2015-09-02 at 19:29 +0100, Andrew Cooper wrote: >> On 02/09/15 18:50, Doug Goldstein wrote: >>> I just wanted to bring this to a top level post since Jonathan=20 >>> Creekmore >>> and myself have talked with a few maintainers in different threads an= d >>> on IRC about potentially using Kconfig and/or Kbuild for Xen. Basical= ly >>> I would like to get a rough idea on what the Xen community wants the >>> system to look like before starting work on it to both save myself ti= me >>> and save maintainers review cycles. So that being said rough proposal= =20 >>> as >>> follows: >>> >>> * target only the xen/ directory tree (i.e. not the toolstack, stubdo= ms >>> or docs) >>> * split top level config bits to not affect xen/ tree (currently only= >>> XSM_ENABLE / FLASK_ENABLE do) >>> * convert xen/ to Kbuild first and merge this in (since Kconfig relie= s >>> on Kbuild-y bits which can be undone but if we're going to go to Kbui= ld >>> in the end why undo it and then redo it) >>> * convert existing xen/ config bits into Kconfig and merge that in >>> >>> Jonathan and I, in a former life, converted a project to Kbuild and >>> Kconfig successfully. I have looked at starting with >>> https://github.com/masahir0y/kbuild_skeleton while the tree is fairly= >>> old it does separate out the build bits from the Linux specific bits >>> pretty nicely while removing module support which arguably is the mos= t >>> complicated part. Alternatively we could start with Linux 4.2 if that= 's >>> more desirable. >> >> Thinking longterm, it would be nice to have xen, tools and stubdoms >> covered by a system like this >=20 > Is the proposal here then to abandon autoconf for the tools subtree in > favour of Kconfig? Or maybe to somehow hybridize autoconf (for e.g. lib= rary > and feature detection) with Kconfig (for user selection of options)? I'= m > not sure how I feel about either of those approaches, they certainly bo= th > need careful consideration, and the second in particular regarding the > interactions... >=20 > FWIW it seems to me that the link between things which are optional in = Xen > and which are optional in the tools is (or should be) pretty loose. i.e= =2E > the tools today _always_ support XSM and correctly handle the errors fr= om > Xen if it is not enabled there. Personally I think this is the right wa= y to > do things. Likewise Xen doesn't care if the tools have particular opini= ons > on the qemu to use or whatever. >=20 > IOW I'm not sure have xen and tools use a common .config would make sen= se. >=20 > Ian. >=20 >=20 So with my initial approach of targeting the xen/ directory how you described it is how it would work. The optional items would be separate and I really think in a lot of cases they are separate like you describe. (e.g. turn off XSM in the hypervisor but not in the tools and the tools gracefully handle that). --=20 Doug Goldstein --hLe3KOuvlB1DAETFw1abQcxNVIUMQPlka 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 iQJ8BAEBCgBmBQJV6FHxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUulUP/0GbvD3fZ0CHGLqC71YZIYbC dQoruZtjJZ9EJhq/bHyR7NVvBv/HrEmMANW8Jt4zNXVTSIwafO3FC9U0kDvAT8Gb gO3HnoZ5mfwO1VvA3WVnLc0bOjG9DWUEZ6U1rlFaKz6wIm/pI0eYK71E4AbEIHtZ Lkov6yHdufOu4KrF1PGYKCIR4xApNumUJH16v1HLS6nBa8GoSZgy004EW9ZY0OAe rQRA6jDws9eXd2teR6uwgZ6zLNLgUGhbgHgfyeM1TZ7Bs7OfJEhsWwzLSNbHYnPI 781vVxMgmVUuB0ZSIzOXSxEVyjjDCE9qLNXSBuv/yJiSyZ5TYNy7xjxaT96tV8q/ sC6bcZsj/a4Fx/hsH3hFNfRW/GgJ/gvwxd33ABq+llJrnLTItEaRndWaKBgWMSEs +MzmdjxUTXzwH4iZdWqcvNMGWbvjWWLofxeCu6dIAxIrmOp0j1Xjy9Z+tquUL1MU 2ZdBDlBWzENgbC8RYaHakv9aa0GaXNNIQOp92YeBZ5rDUoe6Z4Orge48vf1Dh4u3 OWsI+JtN/yxklpjDB91nyv+YlAORayZY/By3y/jJXzyyfJEAErvhJf8kV5dUzj9w I+L8j/7etIV34BDnDoKPvnppEkw+3CnZBSBYFd848MU7bxa2M/Q48+qmHEf3o0l9 4HTcKUioKFajpe0cZIJ3 =8AXW -----END PGP SIGNATURE----- --hLe3KOuvlB1DAETFw1abQcxNVIUMQPlka-- --===============8201466249894260752== 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 --===============8201466249894260752==--