Re: [Xen-devel] [PATCHv6] 01/28] build: import Kbuild/Kconfig from Linux 4.2

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

It is much easier to resync based on entire directories (my preference, if
possible) than to fiddle around picking up individual files, deciding if a
"new" file is actually new or just excluded last time for some reason etc.

> 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),

Only if someone wants to use it. I see no harm in having such a frontend
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 the
standard set of Xen build deps.

I believe this is the policy in the Linux tree too.

> - 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,

I disagree with the (implied) conclusion here that you would somehow be
personally on the hook for these regular updates if we would import only
50% of this kconfig code base, nor that there would therefore be some sort
of additional personal burden on you if we take the whole thing. We should
be arranging that the maintenance burden is ~0 by rejecting diversion and
making the reimport process as brain-dead as possible.

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).

But I honestly don't think this code is going to require much maintenance
at all on our end, apart from the very occasional reimporting of the whole
thing from Linux when we notice some major missing feature we care about,
which is the case that Ian and I are arguing we should optimise for.

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 feature
requests which should redirected upstream and the results reimported.

I think this is all backed up by the fact that after this initial import
the remainder of this series consists of:

$ 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(+)

(The first of which seems like it ought to be fixed upstream instead and it
might even be possible to avoid the latter and therefore avoid the
consequential renaming of the upstream Makefile => Makefile.linux by using
xen/scripts/Makefile.kconfig somehow).

> - avoiding code (scripts) that seem completely pointless in our
> environment (e.g. streamline_config.pl).

I think the overhead of a few extra files of marginal usefulness is far
outweighed by being able to just resync a whole directory.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel