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

[Doug Goldstein <cardoe@xxxxxxxxxx>]

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

I've done the Makefile -> Makefile.kconfig you suggested. As far as the
.gitignore 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.

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


-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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