All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Roy Franz <roy.franz@linaro.org>
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 V2 01/12] Create efi-shared.[ch], and move string functions
Date: Thu, 07 Aug 2014 07:17:44 +0100	[thread overview]
Message-ID: <53E336280200007800029FCC@mail.emea.novell.com> (raw)
In-Reply-To: <CAFECyb-muQQA=94C+wNY6t+Qp3f-=37-n8jdX-2Fqj=nbF1Wkw@mail.gmail.com>

>>> On 07.08.14 at 01:55, <roy.franz@linaro.org> wrote:
> On Mon, Jul 28, 2014 at 9:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 28.07.14 at 18:04, <Ian.Campbell@citrix.com> wrote:
>>> Rather than arch .c files including common .c (or .inc) files how about
>>> making xen/arch/*/efi/Makefile link xen/commmon/efi/built-in.o into it's
>>> own built-in.o instead of having xen/common/Makefile do it like would
>>> normally happen?
>>
>> That's an option. But I agree the inclusion of .c in another .c isn't
>> really nice; I would therefore anyway favor a (set of) arch header
>> file(s) providing everything the common code can't do on its own.
> 
> I think I have pretty good handle addressing all of the feedback with
> the exception of this build issue. Jan - I don't understand your above
> suggestion.

The process would be
- move all files containing pieces you want to re-use from arch/x86/efi/
  to common/efi/, with no other changes than to make them build again
- possibly in a step by step manner, replace any code portions not
  suitable for non-x86 by inline functions placed in said header
- add ARM variants of anything moved to the x86-specific helper
  header (and possible empty x86 variants of stuff ARM needs that
  x86 doesn't)

> Another way to handle this would be for the x86 EFI code to copy
> (or link) the efi-shared.c file locally for building, where it's use would
> be controlled by the PE/COFF toolchain autodetection.  It seems that
> some kind of games will need to be played to have the autodetection
> cooperate with building shared code.

Yes, that would be an option too, with the linking done in a prerequisite
build step. While I generally dislike this model, I do see its simplicity
being a possible advantage here.

Jan

  reply	other threads:[~2014-08-07  6:17 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-22  0:43 [PATCH V2 00/12] arm64 EFI stub Roy Franz
2014-07-22  0:43 ` [PATCH V2 01/12] Create efi-shared.[ch], and move string functions Roy Franz
2014-07-23 16:31   ` Jan Beulich
2014-07-28 15:41     ` Ian Campbell
2014-07-28 15:52       ` Jan Beulich
2014-07-28 15:56         ` Ian Campbell
2014-07-28 16:00           ` Jan Beulich
2014-07-28 16:04             ` Ian Campbell
2014-07-28 16:10               ` Jan Beulich
2014-08-06 23:55                 ` Roy Franz
2014-08-07  6:17                   ` Jan Beulich [this message]
2014-08-09  0:27                     ` Roy Franz
2014-08-06 23:42     ` Roy Franz
2014-07-22  0:43 ` [PATCH V2 02/12] rename printErrMsg to PrintErrMesgExit Roy Franz
2014-07-23 16:33   ` Jan Beulich
2014-07-22  0:43 ` [PATCH V2 03/12] Refactor get_parent_handle for sharing Roy Franz
2014-07-23 16:37   ` Jan Beulich
2014-07-22  0:43 ` [PATCH V2 04/12] Refactor read_file() so it can be shared Roy Franz
2014-07-24  7:09   ` Jan Beulich
2014-08-06 18:38     ` Roy Franz
2014-08-07  6:20       ` Jan Beulich
2014-08-07 17:26         ` Roy Franz
2014-07-22  0:43 ` [PATCH V2 05/12] replace split_value() with truncate_string() Roy Franz
2014-07-24  7:19   ` Jan Beulich
2014-08-06 22:37     ` Roy Franz
2014-08-07  6:24       ` Jan Beulich
2014-08-18 23:38         ` Roy Franz
2014-08-19 12:56           ` Jan Beulich
2014-07-22  0:43 ` [PATCH V2 06/12] add read_config_file() function for XEN EFI config file Roy Franz
2014-07-24  7:32   ` Jan Beulich
2014-08-06 22:42     ` Roy Franz
2014-07-22  0:43 ` [PATCH V2 07/12] create handle_cmdline() function Roy Franz
2014-07-24  7:36   ` Jan Beulich
2014-07-28 15:44     ` Ian Campbell
2014-07-28 15:57       ` Jan Beulich
2014-07-22  0:43 ` [PATCH V2 08/12] Refactor get_argv() for sharing Roy Franz
2014-07-24  7:38   ` Jan Beulich
2014-07-22  0:43 ` [PATCH V2 09/12] Move shared EFI functions to efi-shared.c Roy Franz
2014-07-22  0:43 ` [PATCH V2 10/12] add arm64 cache flushing code from linux Roy Franz
2014-07-28 15:53   ` Ian Campbell
2014-07-28 16:24     ` Ian Campbell
2014-07-22  0:43 ` [PATCH V2 11/12] Add fdt_create_empty_tree() function Roy Franz
2014-07-22 16:36   ` [Linaro-uefi] " Julien Grall
2014-07-22 17:12     ` Roy Franz
2014-07-22 17:15       ` Julien Grall
2014-07-23  9:58         ` Ian Campbell
2014-07-23 16:15           ` Roy Franz
2014-07-22  0:43 ` [PATCH V2 12/12] Add EFI stub for arm64 Roy Franz
2014-07-29  9:46   ` Ian Campbell
2014-07-28 15:30 ` [PATCH V2 00/12] arm64 EFI stub Ian Campbell

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=53E336280200007800029FCC@mail.emea.novell.com \
    --to=jbeulich@suse.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=fu.wei@linaro.org \
    --cc=keir@xen.org \
    --cc=linaro-uefi@lists.linaro.org \
    --cc=roy.franz@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.