From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roy Franz Subject: Re: [PATCH V3 01/15] move x86 EFI boot code to common/efi Date: Mon, 8 Sep 2014 14:00:57 -0700 Message-ID: References: <1410148441-18684-1-git-send-email-roy.franz@linaro.org> <1410148441-18684-2-git-send-email-roy.franz@linaro.org> <1410189797.3680.59.camel@kazak.uk.xensource.com> <540DE8720200007800032263@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <540DE8720200007800032263@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: keir , Ian Campbell , tim , xen-devel , Stefano Stabellini , linaro-uefi , Fu Wei List-Id: xen-devel@lists.xenproject.org On Mon, Sep 8, 2014 at 8:33 AM, Jan Beulich wrote: >>>> On 08.09.14 at 17:23, 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. I think this will be the cleanest - that will allow ARM to use the standard common build stuff, and x86 to do exactly what it did before. I'll do this in the next version. > > 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 >