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: Thu, 3 Dec 2015 10:04:51 -0600 Message-ID: <56606823.4060300@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> <565C6C7B.4060600@cardoe.com> <22108.28242.983982.939049@mariner.uk.xensource.com> <565C8F7702000078000BA686@prv-mh.provo.novell.com> <22108.33931.22008.162522@mariner.uk.xensource.com> <565D8BEA02000078000BAA3D@prv-mh.provo.novell.com> <1449052750.4424.33.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6530135664241784724==" Return-path: In-Reply-To: <1449052750.4424.33.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 , Jan Beulich , Ian Jackson Cc: Tim Deegan , Keir Fraser , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============6530135664241784724== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tIFiXUDiE8bfwGaMoIOEhtTNhmR2UcASM" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tIFiXUDiE8bfwGaMoIOEhtTNhmR2UcASM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/2/15 4:39 AM, Ian Campbell wrote: > On Tue, 2015-12-01 at 04:00 -0700, Jan Beulich wrote: >> But not forking doesn't mean importing the whole directory. Some >> Makefile adjustments will be necessary anyway, so removing some >> of the frontends wouldn't make things worse. We indeed should >> avoid editing files we import, but I don't see any bad in skipping >> some of the files. >=20 > It is much easier to resync based on entire directories (my preference,= if > possible) than to fiddle around picking up individual files, deciding i= f a > "new" file is actually new or just excluded last time for some reason e= tc. >=20 >> Reasons I'd like to avoid importing everything: >> - no introduction of new build dependencies (one of the frontends >> being written in C++ is the mildest form, requiring HOSTCXX to be >> set), >=20 > Only if someone wants to use it. I see no harm in having such a fronten= d > optionally available to those who are willing to meet its prerequisites= in > their build environment, that certainly doesn't mean it has to work for= > everyone nor that we should add a C++ compiler and QT environment to th= e > standard set of Xen build deps. >=20 > I believe this is the policy in the Linux tree too. >=20 >> - limiting the amount of new code that needs maintaining (no >> matter how simple a re-import, it still is work, and hence the less >> frequently we need to do this, the better; I assume you agree >> that the likelihood for changes that we want/need to pull in >> grows with the size of the code, and with what I propose the >> import size would shrink by almost 50%), unless you or Doug >> volunteer to look after this code on a regular basis, >=20 > I disagree with the (implied) conclusion here that you would somehow be= > personally on the hook for these regular updates if we would import onl= y > 50% of this kconfig code base, nor that there would therefore be some s= ort > of additional personal burden on you if we take the whole thing. We sho= uld > be arranging that the maintenance burden is ~0 by rejecting diversion a= nd > making the reimport process as brain-dead as possible. >=20 > Nonetheless if you don't want this to formally come under the remit of = "THE > REST" then I'd happy to see an entry for xen/tools/kconfig in the > MAINTAINERS listing whoever wants to step up (Doug, Ian and/or myself).= >=20 > But I honestly don't think this code is going to require much maintenan= ce > at all on our end, apart from the very occasional reimporting of the wh= ole > thing from Linux when we notice some major missing feature we care abou= t, > which is the case that Ian and I are arguing we should optimise for. >=20 > And having put aside suggestions such as renaming Kconfig to Xconfig > throughout I also don't foresee making very many large changes to this = code > base at all, there's simply no reason to do so, at least none which can= 't > be pushed back on. At worst I would expect to see generic Kconfig featu= re > requests which should redirected upstream and the results reimported. >=20 > I think this is all backed up by the fact that after this initial impor= t > the remainder of this series consists of: >=20 > $ git fetch https://github.com/cardoe/xen kconfig_v6 > From https://github.com/cardoe/xen > * branch kconfig_v6 -> FETCH_HEAD > $ git diff --stat a28f2c4~1 FETCH_HEAD -- xen/scripts/kconfig > xen/scripts/kconfig/.gitignore | 3 +++ > xen/scripts/kconfig/Makefile | 77 ++++++++++++++++++++++++++++++++++= +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 80 insertions(+) >=20 > (The first of which seems like it ought to be fixed upstream instead an= d it > might even be possible to avoid the latter and therefore avoid the > consequential renaming of the upstream Makefile =3D> Makefile.linux by = using > xen/scripts/Makefile.kconfig somehow). I've done the Makefile -> Makefile.kconfig you suggested. As far as the =2Egitignore goes the Linux kernel ignores ALL .* files and explicitly un-ignores dot-files they want to keep. So not sure if they would accept a change upstream. >=20 >> - avoiding code (scripts) that seem completely pointless in our >> environment (e.g. streamline_config.pl). >=20 > I think the overhead of a few extra files of marginal usefulness is far= > outweighed by being able to just resync a whole directory. >=20 > Ian. >=20 --=20 Doug Goldstein --tIFiXUDiE8bfwGaMoIOEhtTNhmR2UcASM 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 iQJ8BAEBCgBmBQJWYGgmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUnfAQAI+gnfFmENwo5K0+V2StIX79 3CMFHpIhGArWUFxcisDfud9giM6bDHu3VEyw5WNOcErKLBgoynclMAxkPV+hpa17 3G4PA9Z4811zkhW7Ysr2y/xrYOBPKlunUywxf7YSQDjZFazCnsyS1TIR1RefolST w105rimsFmCMA8YKxewk2ru3ERYm+6355DYLHHHdbYn0fEuShb2z+9YJTXtY5iP5 lmQ9qH8AzcNQM11hLmLgPFUx+agI608YrdG7/+o91X9V5QYM59weZ9tP4Y40AOwn AVCkiVphQ9jm+WC8crT9q5YNcDZsy77hX75mALqiMwH8mqqiKcDk+2zHGLPrKBTt 1is4sI6J6q/9nPQgEhEA3JSFSoW1LZQeLl2TDFKWY8/CPKvqtVnun6HrqizKIjlA GvC8P3ak1+fGEbnqx2PjdJ8ryk+nxHuvpPI9F/SaGnpgSCeE0S6hVBgAdWZAjYqy tcjMebvshoURgk0vtMlhYI6Fq/gPA65r+X+aq32vs3OZV92YH+bdoK9rvrYh5qzY sjU+wAN6YLFcdPpL9Qt9PNfy6QTgql4BoSn1WxgDlIqh0Bg3CUygHdUpIe4pjGoj 0f9mQQxsHeaCM4AHJQZE2aLrDKXnPqb+aJIkHm1N3F9YsDmBeYrD1jW5HfgsY12/ DIV+E6IJmY/zonmjtLtr =6RSw -----END PGP SIGNATURE----- --tIFiXUDiE8bfwGaMoIOEhtTNhmR2UcASM-- --===============6530135664241784724== 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 --===============6530135664241784724==--