From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: keir <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
tim <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
Stefano Stabellini <stefano.stabellini@citrix.com>,
linaro-uefi <linaro-uefi@lists.linaro.org>,
Fu Wei <fu.wei@linaro.org>
Subject: Re: [PATCH V3 01/15] move x86 EFI boot code to common/efi
Date: Mon, 8 Sep 2014 14:00:57 -0700 [thread overview]
Message-ID: <CAFECyb8MH5VCSskgMf=9wzYOo-AnQ2Sm4k0afBWRnBH=MefH+Q@mail.gmail.com> (raw)
In-Reply-To: <540DE8720200007800032263@mail.emea.novell.com>
On Mon, Sep 8, 2014 at 8:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 08.09.14 at 17:23, <Ian.Campbell@citrix.com> 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
>
next prev parent reply other threads:[~2014-09-08 21:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-08 3:53 [PATCH V3 00/15] arm64 EFI stub Roy Franz
2014-09-08 3:53 ` [PATCH V3 01/15] move x86 EFI boot code to common/efi Roy Franz
2014-09-08 15:23 ` Ian Campbell
2014-09-08 15:33 ` Jan Beulich
2014-09-08 21:00 ` Roy Franz [this message]
2014-09-08 3:53 ` [PATCH V3 02/15] Move x86 specific funtions/variables to arch header Roy Franz
2014-09-08 3:53 ` [PATCH V3 03/15] create arch functions to get and process EFI memory map Roy Franz
2014-09-08 3:53 ` [PATCH V3 04/15] Add architecture functions for pre/post ExitBootServices Roy Franz
2014-09-08 3:53 ` [PATCH V3 05/15] Add efi_arch_cfg_file() to handle arch specific cfg file fields Roy Franz
2014-09-08 3:53 ` [PATCH V3 06/15] Add efi_arch_handle_cmdline() for processing commandline Roy Franz
2014-09-08 3:53 ` [PATCH V3 07/15] Move x86 specific video and disk probing code Roy Franz
2014-09-08 3:53 ` [PATCH V3 08/15] Add efi_arch_memory() for arch specific memory setup Roy Franz
2014-09-08 3:53 ` [PATCH V3 09/15] Add arch specific module handling to read_file() Roy Franz
2014-09-08 3:53 ` [PATCH V3 10/15] Add SMBIOS and runtime services setup arch functions Roy Franz
2014-09-08 3:53 ` [PATCH V3 11/15] Add several misc. arch functions for EFI boot code Roy Franz
2014-09-08 3:53 ` [PATCH V3 12/15] Add efi_arch_use_config_file() function to control use of config file Roy Franz
2014-09-08 3:53 ` [PATCH V3 13/15] add arm64 cache flushing code from linux v3.16 Roy Franz
2014-09-08 15:52 ` Ian Campbell
2014-09-08 3:54 ` [PATCH V3 14/15] Update libfdt to v1.4.0 Roy Franz
2014-09-08 15:54 ` Ian Campbell
2014-09-08 19:08 ` Roy Franz
2014-09-09 9:23 ` Ian Campbell
2014-09-08 3:54 ` [PATCH V3 15/15] Add ARM EFI boot support Roy Franz
2014-09-08 16:12 ` Ian Campbell
2014-09-08 21:18 ` Roy Franz
2014-09-09 9:24 ` Ian Campbell
2014-09-09 9:53 ` Jan Beulich
2014-09-09 17:10 ` Roy Franz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFECyb8MH5VCSskgMf=9wzYOo-AnQ2Sm4k0afBWRnBH=MefH+Q@mail.gmail.com' \
--to=roy.franz@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=fu.wei@linaro.org \
--cc=keir@xen.org \
--cc=linaro-uefi@lists.linaro.org \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).