linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/5] efi: efistub: refactor stub components
Date: Tue, 1 Jul 2014 17:18:08 +0200	[thread overview]
Message-ID: <CAKv+Gu9tY7RqVXdWejwOPnpBTX0S5M9QxBH2te71kpysOV3vWA@mail.gmail.com> (raw)
In-Reply-To: <20140701151130.GF7539@console-pimps.org>

On 1 July 2014 17:11, Matt Fleming <matt@console-pimps.org> wrote:
> On Thu, 26 Jun, at 04:23:36PM, Ard Biesheuvel wrote:
>> In order to move from the #include "../../../xxxxx.c" anti-pattern used by
>> both the x86 and arm64 versions of the stub to a static library linked into
>> either the kernel proper (arm64) or a separate boot executable (x86), there
>> is some prepatory work required.
>>
>> This patch does the following:
>> - move forward declarations of functions shared between the arch specific and
>>   the generic parts of the stub to include/linux/efi.h
>> - move forward declarations of functions shared between various .c files of the
>>   generic stub code to a new local header file called "efistub.h"
>> - add #includes to all .c files which were formerly relying on the #includor to
>>   include the correct header files
>> - remove all static modifiers from functions which will need to be externally
>>   visible once we move to a static library
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> [...]
>
>> diff --git a/include/linux/efi.h b/include/linux/efi.h
>> index 0ceb816bdfc2..3a64f2f85821 100644
>> --- a/include/linux/efi.h
>> +++ b/include/linux/efi.h
>> @@ -1163,4 +1163,46 @@ static inline void
>>  efi_runtime_map_setup(void *map, int nr_entries, u32 desc_size) {}
>>  #endif
>>
>> +/* prototypes shared between arch specific and generic stub code */
>> +
>> +#define pr_efi(sys_table, msg)     efi_printk(sys_table, "EFI stub: "msg)
>> +#define pr_efi_err(sys_table, msg) efi_printk(sys_table, "EFI stub: ERROR: "msg)
>> +
>> +void efi_printk(efi_system_table_t *sys_table_arg, char *str);
>> +
>> +void efi_free(efi_system_table_t *sys_table_arg, unsigned long size,
>> +           unsigned long addr);
>> +
>> +char *efi_convert_cmdline(efi_system_table_t *sys_table_arg,
>> +                       efi_loaded_image_t *image, int *cmd_line_len);
>> +
>
> We've been very good so far at not splattering include/linux/efi.h with
> any of the EFI boot stub prototypes, and it would be awesome if we
> didn't have to start now.
>
> Is there any way we could avoid doing this? Arguably everything should
> be in the new efistub.h, no?
>

There are bits that are shared between code under arch/xxx and
drivers/firmware/efi, and what those bits are is different between the
archs. I used <asm/efi.h> just for convenience, but perhaps we could
add <asm/efistub.h> for each arch, and #include it in both "efistub.h"
under drivers/firmware/efi and the stub bits that live under arch/xxx?
Then any other users of <asm/efi.h> won't have to see it.

-- 
Ard.

  reply	other threads:[~2014-07-01 15:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-26 14:23 [PATCH v2 0/5] efistub: convert into static library Ard Biesheuvel
2014-06-26 14:23 ` [PATCH v2 1/5] efi/arm64: avoid EFI_ERROR as a generic return code Ard Biesheuvel
2014-06-26 14:23 ` [PATCH v2 2/5] efi/x86: efistub: move shared dependencies to <asm/efi.h> Ard Biesheuvel
2014-07-02 12:59   ` Mark Salter
2014-07-02 13:02     ` Ard Biesheuvel
2014-06-26 14:23 ` [PATCH v2 3/5] efi/arm64: " Ard Biesheuvel
2014-06-26 14:23 ` [PATCH v2 4/5] efi: efistub: refactor stub components Ard Biesheuvel
2014-07-01 15:11   ` Matt Fleming
2014-07-01 15:18     ` Ard Biesheuvel [this message]
2014-07-01 15:20       ` Ard Biesheuvel
2014-07-01 16:22         ` Matt Fleming
2014-06-26 14:23 ` [PATCH v2 5/5] efi: efistub: convert into static library Ard Biesheuvel
2014-07-02 11:15   ` Matt Fleming
2014-07-02 11:23     ` Ard Biesheuvel
2014-07-02 11:49       ` Ard Biesheuvel
2014-07-01 18:39 ` [PATCH v2 0/5] " Matt Fleming
2014-07-01 18:55   ` Ard Biesheuvel
2014-07-01 19:01     ` Matt Fleming

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=CAKv+Gu9tY7RqVXdWejwOPnpBTX0S5M9QxBH2te71kpysOV3vWA@mail.gmail.com \
    --to=ard.biesheuvel@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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).