From: Ingo Molnar <mingo@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-efi@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Colin Ian King <colin.king@canonical.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 12/12] efi: make const array 'apple' static
Date: Fri, 9 Mar 2018 09:31:15 +0100 [thread overview]
Message-ID: <20180309083115.mvnrtvukc7sqe2i2@gmail.com> (raw)
In-Reply-To: <CAKv+Gu86v9-Cj3bxEPWXCMRnE7S76kGdu7to3cOoLMgTTcH_xg@mail.gmail.com>
* Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 9 March 2018 at 08:04, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >
> >> > Also, would it make sense to rename it to something more descriptive like
> >> > "apple_unicode_str[]" or so?
> >> >
> >> > Plus an unicode string literal initializer would be pretty descriptive as well,
> >> > instead of the weird looking character array, i.e. something like:
> >> >
> >> > static efi_char16_t const apple_unicode_str[] = u"Apple";
> >> >
> >> > ... or so?
> >> >
> >>
> >> is u"xxx" the same as L"xxx"?
> >
> > So "L" literals map to wchar_t, which wide character type is implementation
> > specific IIRC, could be 16-bit or 32-bit wide.
> >
> > u"" literals OTOH are specified by the C11 spec to be char16_t, i.e. 16-bit wide
> > characters - which I assume is the EFI type as well?
> >
> >> In any case, this is for historical reasons: at some point (and I
> >> don't remember the exact details) we had a conflict at link time with
> >> objects using 4 byte wchar_t, so we started using this notation to be
> >> independent of the size of wchar_t. That issue no longer exists so we
> >> should be able to get rid of this.
> >
> > Yes, my guess is that those problems were due to L"xyz" mapping to wchar_t and
> > having a different type in the kernel build and the host build side - but u"xyz"
> > should solve that.
> >
>
> Excellent!
Please double check the generated code though, all of this is from memory.
> Do you mind taking this patch as is? I will follow up with a patch
> that updates all occurrences of this pattern (we have a few of them),
> i.e., use u"" notation and move them to file scope.
Sure, done!
Thanks,
Ingo
next prev parent reply other threads:[~2018-03-09 8:31 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-08 8:00 [GIT PULL 00/12] first batch of EFI changes for v4.17 Ard Biesheuvel
2018-03-08 8:00 ` Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 01/12] efi/arm*: Only register page tables when they exist Ard Biesheuvel
2018-03-09 9:11 ` [tip:efi/core] " tip-bot for Mark Rutland
2018-03-08 8:00 ` [PATCH 02/12] efi/apple-properties: Device core takes care of empty properties Ard Biesheuvel
2018-03-09 9:11 ` [tip:efi/core] efi/apple-properties: Remove redundant attribute initialization from unmarshal_key_value_pairs() tip-bot for Andy Shevchenko
2018-03-08 8:00 ` [PATCH 03/12] efi/arm*: Stop printing addresses of virtual mappings Ard Biesheuvel
2018-03-09 9:12 ` [tip:efi/core] " tip-bot for Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 04/12] efi/x86: Fix trailing semicolons Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 05/12] efi: arm64: Check whether x18 is preserved by runtime services calls Ard Biesheuvel
2018-03-09 9:12 ` [tip:efi/core] efi/arm64: " tip-bot for Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 06/12] x86: efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store Ard Biesheuvel
2018-03-09 7:54 ` Ingo Molnar
2018-03-09 9:13 ` [tip:efi/core] x86/efi: Replace GFP_ATOMIC with GFP_KERNEL in efi_query_variable_store() tip-bot for Jia-Ju Bai
2018-03-08 8:00 ` [PATCH 07/12] efi: Use efi_mm in x86 as well as ARM Ard Biesheuvel
2018-03-09 7:40 ` Ingo Molnar
2018-03-09 8:37 ` Prakhya, Sai Praneeth
2018-03-09 9:56 ` Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 08/12] x86/efi: Replace efi_pgd with efi_mm.pgd Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 09/12] x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3 Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 10/12] efi: reorder pr_notice() with add_device_randomness() call Ard Biesheuvel
2018-03-09 9:13 ` [tip:efi/core] efi: Reorder " tip-bot for Ard Biesheuvel
2018-03-08 8:00 ` [PATCH 11/12] efi/apple-properties: Use memremap() instead of ioremap() Ard Biesheuvel
2018-03-09 9:14 ` [tip:efi/core] " tip-bot for Andy Shevchenko
2018-03-08 8:00 ` [PATCH 12/12] efi: make const array 'apple' static Ard Biesheuvel
2018-03-08 11:05 ` Joe Perches
2018-03-09 7:43 ` Ard Biesheuvel
2018-03-09 7:44 ` Ard Biesheuvel
2018-03-09 9:37 ` Joe Perches
2018-03-09 7:47 ` Ingo Molnar
2018-03-09 7:52 ` Ard Biesheuvel
2018-03-09 8:04 ` Ingo Molnar
2018-03-09 8:07 ` Ard Biesheuvel
2018-03-09 8:19 ` Ard Biesheuvel
2018-03-09 8:31 ` Ingo Molnar [this message]
2018-03-09 8:29 ` Lukas Wunner
2018-03-09 8:33 ` Ard Biesheuvel
2018-03-09 9:16 ` [tip:efi/core] efi: Make " tip-bot for Colin Ian King
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=20180309083115.mvnrtvukc7sqe2i2@gmail.com \
--to=mingo@kernel.org \
--cc=ard.biesheuvel@linaro.org \
--cc=colin.king@canonical.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 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.