From: Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
To: "H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>,
Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>,
Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>,
Matt Fleming
<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 06/13] x86/efi: Build our own EFI services pointer table
Date: Fri, 28 Feb 2014 14:12:06 +0000 [thread overview]
Message-ID: <20140228141206.GA17881@console-pimps.org> (raw)
In-Reply-To: <530F9B71.1030405-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
On Thu, 27 Feb, at 12:09:21PM, H. Peter Anvin wrote:
>
> That being said, is there a reason we can't simply write this as:
>
> efi_system_table_##bits##_t table;
>
> /* ... */
>
> func = (typeof(func))(unsigned long)table->con_out;
> c->text_output = *func;
Oh, yeah that's much better. I was being overly cautious with trying to
not dereference the pointers in the regular efi_system_table_t, and what
you've written is much more compact both in terms of C and generated
object code. Things end up looking like this,
---
#define BOOT_SERVICES(bits) \
static void setup_boot_services##bits(struct efi_config *c) \
{ \
efi_system_table_##bits##_t *table; \
efi_boot_services_##bits##_t *bt; \
\
table = (typeof(table))sys_table; \
\
c->text_output = table->con_out; \
\
bt = (typeof(bt))(unsigned long)(table->boottime); \
\
c->allocate_pool = bt->allocate_pool; \
c->allocate_pages = bt->allocate_pages; \
c->get_memory_map = bt->get_memory_map; \
c->free_pool = bt->free_pool; \
c->free_pages = bt->free_pages; \
c->locate_handle = bt->locate_handle; \
c->handle_protocol = bt->handle_protocol; \
c->exit_boot_services = bt->exit_boot_services; \
}
BOOT_SERVICES(32);
BOOT_SERVICES(64);
--
Matt Fleming, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-02-28 14:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-27 19:50 [PATCH 00/13] EFI mixed mode Matt Fleming
[not found] ` <1393530660-12692-1-git-send-email-matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-02-27 19:50 ` [PATCH 01/13] x86/boot: Cleanup header.S by removing some #ifdefs Matt Fleming
2014-02-27 19:50 ` [PATCH 02/13] x86, tools: Consolidate #ifdef code Matt Fleming
2014-02-27 19:50 ` [PATCH 03/13] x86/mm/pageattr: Always dump the right page table in an oops Matt Fleming
2014-02-27 19:50 ` [PATCH 04/13] x86/efi: Delete dead code when checking for non-native Matt Fleming
2014-02-27 19:50 ` [PATCH 05/13] efi: Add separate 32-bit/64-bit definitions Matt Fleming
2014-02-27 19:50 ` [PATCH 06/13] x86/efi: Build our own EFI services pointer table Matt Fleming
[not found] ` <1393530660-12692-7-git-send-email-matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-02-27 20:09 ` H. Peter Anvin
[not found] ` <530F9B71.1030405-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2014-02-28 14:12 ` Matt Fleming [this message]
[not found] ` <20140228141206.GA17881-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-02-28 15:14 ` H. Peter Anvin
2014-02-27 19:50 ` [PATCH 07/13] x86/efi: Add early thunk code to go from 64-bit to 32-bit Matt Fleming
2014-02-27 19:50 ` [PATCH 08/13] x86/efi: Split the boot stub into 32/64 code paths Matt Fleming
2014-02-27 19:50 ` [PATCH 09/13] x86/efi: Firmware agnostic handover entry points Matt Fleming
2014-02-27 19:50 ` [PATCH 10/13] x86/efi: Add mixed runtime services support Matt Fleming
2014-02-27 19:50 ` [PATCH 11/13] x86/efi: Wire up CONFIG_EFI_MIXED Matt Fleming
2014-02-27 19:50 ` [PATCH 12/13] x86/boot: Don't overwrite cr4 when enabling PAE Matt Fleming
2014-02-27 19:51 ` [PATCH 13/13] x86/efi: Re-disable interrupts after calling firmware services 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=20140228141206.GA17881@console-pimps.org \
--to=matt-hnk1s37rvnbexh+ff434mdi2o/jbrioy@public.gmane.org \
--cc=alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org \
--cc=bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org \
--cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.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).