Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-11-02 at 09:11 -0700, Jan Beulich wrote:
> > > >Â
> > It seems quite inconsistent to me to have xen/arch/x86/x86_64/Makefile
> > building some files directly and xen/arch/x86/Makefile to be building
> > another subset of those files via x86_64/FOO.o. Even more so that other
> > than compat.o I can't see what makes many affected files (e.g. mm.o or
> > platform_hypercall.o) special in this regard.
> 
> The platform_hypercall one is quite obvious, because
> x86_64/platform_hypercall.c just includes platform_hypercall.c
> (which is the general pattern we're dealing with here). For mm.c
> it was just prompted by actual collisions seen.

Neither of those seem obvious to me.

> > Does all of that fall out from a desire to reuse __FILE__? If so I'm
> > inclined to suggest that -DBUILD_FILENAME_PREFIX="compat/" or whatever
> > would seem likely to me to end up less strange (but maybe you tried
> > that
> > and it was worse?).
> 
> Yes to the first question. And no, I didn't try the alternative you
> suggest, but discarded it as the uglier variant from the beginning.
> In particular I dislike (parts of) file names to be specified on the
> command line, rather than getting derived from what we have
> anyway.

Hrm, ok.

What I was actually thinking (but not expressing very well in the example I
gave) was that the code being compiled a second time in "compat" mode would
be tagged as that, e.g. by listing them in obj-compat-y and adding
something to CFLAGS (which may or may not look like a subpath, it might
e.g. just be "(compat)").

Many of the double compiled files end up #defineing COMPAT, even without
moving that to CFLAGS isn't that enough to key such a distinction on.

> Considering that Andrew was fine with the x86 parts, I'd want to
> change the approach (the x86 side of which I understand is of
> particular concern to you) only if you're convinced this alternative
> approach is sufficiently much better.

I'm mostly concerned with precedent being set by x86 and also implied by
the common code Makefile infra which supports it causing people to think it
is acceptable outside of x86.

I wouldn't ack an arm patch which made it such that the files in a single
subdirectory fell in two "classes" like this, and I'd probably argue more
strongly against it if it was being used in common code.

As it is today only for x86 I suppose I have no real grounds to nack it,
except to preemptively nack any use of it outside of x86.

Ian.

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