linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Matthew Garrett <matthewgarrett@google.com>,
	Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 13/21] efi/libstub/x86: drop __efi_early() export of efi_config struct
Date: Thu, 2 Jan 2020 08:33:54 +0100	[thread overview]
Message-ID: <CAKv+Gu-XRgRXgiuDEe+DXdcEzOuUWG6fWMO_oa41f2Ugki5kCA@mail.gmail.com> (raw)
In-Reply-To: <20200101190844.GA208136@rani.riverdale.lan>

On Wed, 1 Jan 2020 at 20:08, Arvind Sankar <nivedita@alum.mit.edu> wrote:
>
> On Wed, Jan 01, 2020 at 07:13:45PM +0100, Ard Biesheuvel wrote:
> > The GCC documentation mentions that it does not make sense for a
> > function annotated as const not to take any arguments, so I'd rather
> > avoid it here.
>
> Where does it say that? I only see it saying it doesn't make sense for
> it to return void.
>

You're right. I looked into this in the past, and I misremembered, and
paraphrased it incorrectly.

The documentation does mention that const functions are not permitted
to read global memory.

> Currently if we call 5 EFI services in the same function, it has to
> re-evaluate systemtable and is64 for each call, which seems wasteful,
> though of course this is not exactly performance-critical code.

The alternative would be to use globals with external linkage in a way
that is guaranteed not to rely on GOT entries, since we'll end up with
absolute addresses that need to be fixed up first. This has caused
breakage in the past, and is the reason we use this scheme with
globals with static linkage and __pure getters.

However, hidden visibility should yield the same results so we should
be able to make it work with that instead. However, given the breakage
in the past, I don't think it's worth it since the performance gain
will be negligible.

  reply	other threads:[~2020-01-02  7:33 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 17:01 [PATCH v2 00/21] efi/x86: confine type unsafe casting to mixed mode Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 01/21] efi/libstub: remove unused __efi_call_early() macro Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 02/21] efi/x86: rename efi_is_native() to efi_is_mixed() Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 03/21] efi/libstub: use a helper to iterate over a EFI handle array Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 04/21] efi/libstub: extend native protocol definitions with mixed_mode aliases Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 05/21] efi/libstub: distinguish between native/mixed not 32/64 bit Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 06/21] efi/libstub/x86: use mixed mode helpers to populate efi_config Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 07/21] efi/libstub: drop explicit 32/64-bit protocol definitions Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 08/21] efi/libstub: use stricter typing for firmware function pointers Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 09/21] efi/libstub: annotate firmware routines as __efiapi Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 10/21] efi/libstub/x86: avoid thunking for native firmware calls Ard Biesheuvel
2019-12-21 21:22   ` Hans de Goede
2019-12-22 12:02     ` Ard Biesheuvel
2019-12-22 12:37       ` Ard Biesheuvel
2019-12-22 12:46       ` Andy Lutomirski
2019-12-22 15:29         ` Ard Biesheuvel
2019-12-22 21:12           ` Arvind Sankar
2019-12-22 21:25             ` Ard Biesheuvel
2019-12-23 11:49       ` Hans de Goede
2019-12-23 12:00         ` Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 11/21] efi/libstub: get rid of 'sys_table_arg' macro parameter Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 12/21] efi/libstub: unify the efi_char16_printk implementations Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 13/21] efi/libstub/x86: drop __efi_early() export of efi_config struct Ard Biesheuvel
2019-12-24 19:34   ` Hans de Goede
2019-12-25 14:42     ` Ard Biesheuvel
2019-12-27 22:44       ` Hans de Goede
2019-12-27 22:51         ` Ard Biesheuvel
2019-12-31 23:04   ` Arvind Sankar
2020-01-01 18:13     ` Ard Biesheuvel
2020-01-01 19:08       ` Arvind Sankar
2020-01-02  7:33         ` Ard Biesheuvel [this message]
2020-01-02 14:06           ` Arvind Sankar
2020-01-02 15:20             ` Ard Biesheuvel
2020-01-02 15:51               ` Arvind Sankar
2020-01-02 15:58                 ` Ard Biesheuvel
2020-01-02 16:28                   ` Ard Biesheuvel
2020-01-02 16:59                     ` Ard Biesheuvel
2020-01-02 17:26                       ` Arvind Sankar
2020-01-02 17:30                         ` Ard Biesheuvel
2020-01-02 17:41                           ` Arvind Sankar
2020-01-02 17:48                             ` Ard Biesheuvel
2020-01-02 18:10                               ` Arvind Sankar
2020-01-02 18:38                                 ` Ard Biesheuvel
2020-01-03 14:16                                   ` Arvind Sankar
2020-01-03 14:23                                     ` Ard Biesheuvel
2020-01-02 18:38                               ` Arvind Sankar
2020-01-02 16:59                     ` Arvind Sankar
2020-01-02 17:03                       ` Ard Biesheuvel
2020-01-02 17:21                         ` Arvind Sankar
2019-12-18 17:01 ` [PATCH v2 14/21] efi/libstub: drop sys_table_arg from printk routines Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 15/21] efi/libstub: remove 'sys_table_arg' from all function prototypes Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 16/21] efi/libstub: drop protocol argument from efi_call_proto() macro Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 17/21] efi/libstub: drop 'table' argument from efi_table_attr() macro Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 18/21] efi/libstub: use 'func' not 'f' as macro parameter Ard Biesheuvel
2019-12-31 16:51   ` Arvind Sankar
2019-12-31 17:06     ` Ard Biesheuvel
2019-12-31 17:36       ` Arvind Sankar
2019-12-18 17:01 ` [PATCH v2 19/21] efi/libstub: tidy up types and names of global cmdline variables Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 20/21] efi/libstub: import type definitions for creating and signalling events Ard Biesheuvel
2019-12-18 17:01 ` [PATCH v2 21/21] efi: Allow disabling PCI busmastering on bridges during boot Ard Biesheuvel
2019-12-19  2:50   ` Andy Lutomirski
2019-12-19 13:17     ` Ard Biesheuvel
2019-12-19 20:04       ` Matthew Garrett
2019-12-19 20:04   ` Matthew Garrett
2019-12-20  7:06     ` Ard Biesheuvel
2019-12-20  7:17       ` Andy Lutomirski
2019-12-20  8:11         ` Ard Biesheuvel
2019-12-20 19:41           ` Arvind Sankar
2020-01-02 14:46             ` Laszlo Ersek
2020-01-02 15:40               ` Ard Biesheuvel
2019-12-20 20:43       ` Matthew Garrett
2019-12-21 16:44         ` Ard Biesheuvel
2019-12-21 21:24           ` Matthew Garrett
2019-12-21 22:54             ` Arvind Sankar
2019-12-23 14:02               ` Ard Biesheuvel
2019-12-23 15:46                 ` Arvind Sankar
2019-12-23 15:58                   ` Ard Biesheuvel
2019-12-23 16:12                     ` Arvind Sankar
2019-12-23 20:57                   ` Matthew Garrett
2020-02-06 14:30   ` Hans de Goede
2020-02-06 14:35     ` Ard Biesheuvel
2020-03-04 10:38       ` Hans de Goede
2020-03-04 18:26         ` Ard Biesheuvel
2020-03-04 18:49           ` Hans de Goede
2020-03-04 21:59             ` Ard Biesheuvel
2019-12-19 11:12 ` [PATCH v2 00/21] efi/x86: confine type unsafe casting to mixed mode Hans de Goede
2019-12-19 13:22   ` Ard Biesheuvel

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+Gu-XRgRXgiuDEe+DXdcEzOuUWG6fWMO_oa41f2Ugki5kCA@mail.gmail.com \
    --to=ard.biesheuvel@linaro.org \
    --cc=ardb@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=matthewgarrett@google.com \
    --cc=mingo@kernel.org \
    --cc=nivedita@alum.mit.edu \
    --cc=tglx@linutronix.de \
    /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).