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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.11.15 at 13:22, <ian.campbell@xxxxxxxxxx> wrote:
> On Mon, 2015-11-02 at 09:11 -0700, Jan Beulich wrote:
>> > 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)").

I definitely want this to be a real path, i.e. a representation allowing
to connect thing to how the source file layout is without any guessing.

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

Of course that would be possible, but since that would mean
e.g. adding #ifdef-s it would clutter the code.

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

Okay, so for common code you didn't object to (but also didn't ack)
the change to compile the whole compat/ subtree from one level up.
That's certainly an option on x86 too, the more that the x86_64/
subtree is a remnant of x86_32 days only anyway. Just that doing
this will mean quite a bit more work (not the least because, to be
done properly, I think it implies merging files from x86_64/ into their
[formerly] shared files where sensible).

Jan


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