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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.11.15 at 18:16, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [PATCHv6] 01/28] build: import Kbuild/Kconfig from 
> Linux 4.2"):
>> On 30.11.15 at 16:42, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>> > I would go further than this, and wholesale import the relevant files
>> > into a subdirectory in a single commit that contains nothing else, and
>> > mention the specific git commit id and version number in the Linux
>> > tree in the commit message.
>> 
>> But what's the point of importing things we're not going to use?
> 
> I thought I had explained that.
> 
> A future re-import or merge will be much simpler if this import is a
> simple wholesale copy of a directory or two or a simple glob pattern.
> 
> The runes used to do the import could be in the commit message for
> easy reproduction.
> 
>> Imo such an import should be limited to those files that (later on)
>> would actually get wired up. Hence the request to do a minimalistic
>> import for this first round.
> 
> This would involve a series of piece-by-piece imports.  Any future
> merge or re-import would involve retracing and re-executing those
> steps.
> 
> It appears that we do disagree.  Perhaps the basic thing is: I don't
> think we want to fork this code.  We want to be a downstream of Linux
> for it.  If necessary we may edit, to an extent, the parts we import,
> but hopefully we'll keep that to a minimum.

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.

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),
- 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,
- avoiding code (scripts) that seem completely pointless in our
environment (e.g. streamline_config.pl).

Jan


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