Re: [Xen-devel] [PATCH V3 01/15] move x86 EFI boot code to common/efi

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.09.14 at 17:23, <Ian.Campbell@xxxxxxxxxx> wrote:
> ink On Sun, 2014-09-07 at 20:53 -0700, Roy Franz wrote:
>> --- a/xen/arch/x86/Makefile
>> +++ b/xen/arch/x86/Makefile
>> @@ -75,6 +75,13 @@ $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
>>  
>>  ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o 
>> $(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
>>  
>> +
>> +# This seems to be required to get parallel builds to work, otherwise 
>> prelink-efi.o complains about
>> +# no rule to make boot.init.o
> 
> I suppose we must recurse into common and arch at the same time.
>> +# Not sure what the right fix is
> 
> Me neither. This doesn't look right to me though, given that
> xen/common/efi is also entered via a subdir-y in xen/common/Makefile.
> 
> Perhaps Jan has some ideas but I'm wondering if we ought not to recurse
> into xen/common/efi from here and not from xen/common, or at least to
> not include extra-$(efi) += boot.init.o in xen/common/efi/Makefile (that
> would also let the x86 specific checkng code stay here, might it?)
> 
> symbols-dummy.o has a similar hack, but notice that it is not build from
> xen/common/Makefile.
> 
> Anyway, I'm flailing, perhaps Jan can suggest the correct fix.

So originally the idea was to sym-link the moved file into its current
location, limiting the build recursion to what is being done today.

The only seamless alternative I can see would be to move the whole
efi/ subtree to common/ (after all, runtime.c will need to be moved at
some point too, and other files should then follow for consistency).

Jan


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