From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig from Linux 4.2 Date: Mon, 30 Nov 2015 09:34:19 -0600 Message-ID: <565C6C7B.4060600@cardoe.com> References: <1448387538-12208-1-git-send-email-cardoe@cardoe.com> <1448387538-12208-2-git-send-email-cardoe@cardoe.com> <565C645C02000078000BA3AD@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2413360728944406826==" Return-path: In-Reply-To: <565C645C02000078000BA3AD@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: Keir Fraser , Tim Deegan , Ian Jackson , 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) --===============2413360728944406826== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GO0mJm9JXju3sFcHOisx5PHTXxLorasch" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GO0mJm9JXju3sFcHOisx5PHTXxLorasch Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/30/15 7:59 AM, Jan Beulich wrote: >>>> On 24.11.15 at 18:51, wrote: >> --- /dev/null >> +++ b/xen/include/linux/kconfig.h >> @@ -0,0 +1,54 @@ >> +#ifndef __LINUX_KCONFIG_H >> +#define __LINUX_KCONFIG_H >=20 > Neither placement in the source tree nor guard variable should say > "Linux". This file gets removed later in the series. I meant to squash that into this patch. >=20 >> --- /dev/null >> +++ b/xen/scripts/Makefile.host >> @@ -0,0 +1,128 @@ >=20 > We already have ways to build host programs. Do we really need a > second mechanism, the more an abstract one? I'd prefer a more > minimalistic approach (confined to the xen/scripts/kconfig/ subtree, > which imo actually should be xen/tools/kconfig/). In any even I'd > expect, for everything outside of the actual kconfig/ subtree, a > few words in the commit message towards the rationale for including > those pieces. That'll help future cleanup by clarifying what certain > pieces are actually needed for. I can move it into xen/scripts/kconfig. The Xen make rules to build host programs leave things to be desired and its actually necessary to use these to build the different config variants. Earlier in the review process (or really the RFC) I suggested bringing those parts of Kbuild into Xen, which would have the effect of providing the ability to build all the necessary pieces but I was told not to. So I'll just move this file into xen/scripts/kconfig. I can also move everything to xen/tools/kconfig. >=20 >> --- /dev/null >> +++ b/xen/scripts/kconfig/.gitignore >> @@ -0,0 +1,22 @@ >=20 > Does the top level one (perhaps suitably adjusted) not fit the needs? The whole point here was to bring in the kconfig bits from Linux 4.2 untouched for traceability for where the code came from. By doing it this way it allows Xen to rebase kconfig support to a newer version much easier since its all self-contained. >=20 >> --- /dev/null >> +++ b/xen/scripts/kconfig/Makefile.linux >> @@ -0,0 +1,317 @@ >=20 > This doesn't seem to be referenced anywhere. Its the central file for building kconfig. Its refereinced in xen/scripts/kconfig/Makefile on line 63. This is the only file I've renamed from its original name in the Linux source tree. >=20 >> --- /dev/null >> +++ b/xen/scripts/kconfig/POTFILES.in >> @@ -0,0 +1,12 @@ >=20 > Do we really need this? If we don't expect to provide localization of kconfig, then no. Granted I didn't wire up the other localization bits. >=20 >> +void expr_print(struct expr *e, void (*fn)(void *, struct symbol *, c= onst char *), void *data, int prevtoken) >> +{ >> + if (!e) { >> + fn(data, NULL, "y"); >> + return; >> + } >> + >> + if (expr_compare_type(prevtoken, e->type) > 0) >> + fn(data, NULL, "("); >> + switch (e->type) { >> + case E_SYMBOL: >> + if (e->left.sym->name) >> + fn(data, e->left.sym, e->left.sym->name); >> + else >> + fn(data, NULL, ""); >> + break; >> + case E_NOT: >> + fn(data, NULL, "!"); >> + expr_print(e->left.expr, fn, data, E_NOT); >> + break; >> + case E_EQUAL: >> + if (e->left.sym->name) >> + fn(data, e->left.sym, e->left.sym->name); >> + else >> + fn(data, NULL, ""); >> + fn(data, NULL, "=3D"); >> + fn(data, e->right.sym, e->right.sym->name); >> + break; >> + case E_LEQ: >> + case E_LTH: >> + if (e->left.sym->name) >> + fn(data, e->left.sym, e->left.sym->name); >> + else >> + fn(data, NULL, ""); >> + fn(data, NULL, e->type =3D=3D E_LEQ ? "<=3D" : "<"); >> + fn(data, e->right.sym, e->right.sym->name); >> + break; >> + case E_GEQ: >> + case E_GTH: >> + if (e->left.sym->name) >> + fn(data, e->left.sym, e->left.sym->name); >> + else >> + fn(data, NULL, ""); >> + fn(data, NULL, e->type =3D=3D E_LEQ ? ">=3D" : ">"); >=20 > Please eliminate the copy-and-paste mistake here right away (see > Linux commit f6aad2615c). In an effort to keep the history clean at 4.2, I'll pull this in as an additional patch to the series. >=20 >> --- /dev/null >> +++ b/xen/scripts/kconfig/gconf.c >> @@ -0,0 +1,1521 @@ >=20 > I think I had asked before, and with us not wanting any user visible > prompts for now I wonder even more: Do we really need [gmnq]conf? > All I think we really need is conf. >=20 > Jan >=20 Well as you (and others) have commented about the fact that KEXEC and the ARM UARTs should be user configurable which is why I included those. So I'll continue to leave those in ok? --=20 Doug Goldstein --GO0mJm9JXju3sFcHOisx5PHTXxLorasch 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 iQJ8BAEBCgBmBQJWXGx+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUFwAP/AmPgqXVUAsvpH9iwimcVbDO txY+iqjkMDNbvPhL8yKKm1ZDzy+QE7+KsnUM9tDJwhavqAQ6OwmMhrBm/2gRyhQ9 rJ9QZmDbzs8eFd0cPQDanZwrXCa0DbeG4n1wr5UYUolA5MJSE8oq2z7oOnehQu2d m+Tg9p6deG5DJqC9Oifz3Of+Ps8JsEbyFqL7arXoThV8ecpA1LR7aayYRY9TSoND frBUsnwmobKuTndyHoX7OYT2m52jPs3W8AOAlAUM0fKcn98UZdowznM7LnEz6R2W E8I+Bw13I8S7Iv7DrdE026XUYCEfx8qKW4IDprlmvdQaoIvMSoxR4Q99WQR2wTTu KDlGqTJpUPi9Po4I01wogjFyW4sAOV2JLP2x94LNFWiUGBOz6Mtzm2uxj0FN+CqA WVu+ArgGGnq6hUKNmNxnVaJiYrkyzIWhBn4iACwqnaDcRShf2scuAtgEq4D/v2UD fFmlUiXFlwB/1GRMoOVVkROY2asoJDFy+/sGxJ/zk3VDLsgdNIoU4wd3szcD0Vkh joV/JHLNC+6H6OjxLWajetBoVAM1kJtcQpboVHw9KKsVk5xENDKatpz9t2vf1SxC aLMiWyOyqLfjzyEyG19Lwdmi3UUw1FErqZh2EcKwl9mQXJbbfK46hlHIDKL9UAAS uPb07vw7Lw4y66ZWvNKL =/yF6 -----END PGP SIGNATURE----- --GO0mJm9JXju3sFcHOisx5PHTXxLorasch-- --===============2413360728944406826== 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 --===============2413360728944406826==--