Re: [XEN PATCH v7 05/51] x86/mm: avoid building multiple .o from a single .c file

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/09/2021 12:44, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [XEN PATCH v7 05/51] x86/mm: avoid building 
> multiple .o from a single .c file"):
>> On Tue, Sep 07, 2021 at 08:14:14AM +0200, Jan Beulich wrote:
>>> Hmm, when replying to 00/51 I didn't recall I gave an R-b for this one
>>> already. I'd like to restrict it some: It should be taken to stand for
>>> the technical correctness of the change. Nevertheless I'm not really
>>> happy with the introduction of the various tiny source files. I've
>>> meanwhile been wondering: Can't these be generated (in the build tree,
>>> as soon as that's possible to be separate) rather than getting put in
>>> the repo?
>> Do we really need to generated those never to be change tiny source
>> file? Do we really need to make the build system a lot more complicated?
> I'm not an x86 maintainer, but my 2p anyway:
>
> I think the handful of tiny source files is probably better than some
> contraption in the build system.  Much less risk of something funny
> and confusing going on.

I agree.  This patch is definitely an improvement on the status quo.

> We could reduce the number of copies of the same text by making the
> copies of guest_walk*.c in hap/ be symlinks to ../guest_walk*.c.

The two guest_walk's are totally different logic.  Adding a symlink
would be reintroducing "something funny and confusing".

>
>> Can't we commit this patch as is? What kind of issue is there with those
>> tiny source files? Should we add a warning in those tiny source files,
>> something like "No modification of this file allowed, it's part of the
>> build system." ?
> I don't think we need any such warning.  No-one is going to take that
> tiny file and try to edit it to put functionality in it, and if they
> do it will be spotted on review.

Agreed.

FTR, this patch is Reviewed-by: Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> and fit to be committed.