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

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-11-03 at 05:50 -0700, Jan Beulich wrote:
> > > > 
> > > 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.

Correct I find it tolerable enough if a given sub directory is either
recursed into or compiled from the parent directory, it's the mixing I
object to.

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

FWIW IMHO compiling arch/x86/x86_64/*.c from arch/x86/Makefile now and then
tackling the merging as and when it makes sense would be fine.

Ian.

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