From: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Leif Lindholm
<leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/3] arm64: efistub: drop __init annotation from handle_kernel_image()
Date: Fri, 29 Jan 2016 16:00:06 +0000 [thread overview]
Message-ID: <20160129160006.GD2611@codeblueprint.co.uk> (raw)
In-Reply-To: <CAKv+Gu9sE4oJrFmSK8sEjTrU8A7k53Hj1S1pTyCqyA5Gsba2Kw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 29 Jan, at 10:36:03AM, Ard Biesheuvel wrote:
> On 28 January 2016 at 23:58, Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:
> >
> > Would it make more sense to #undef __init in one of the arm64 efistub
> > header files? I'm thinking of the case where some poor unsuspecting
> > developer writes a new function and marks it as __init, and we miss it
> > during review.
> >
>
> Yes, I can add it to efistub.h, and make sure it gets included in all the files
>
> Should we #undef it and #define it to a string that is easily grep'ed
> for, so it is easy to find the explanatory comment that goes along
> with it?
> E.g.,
>
> #define __init __init_not_supported_in_efi_stub
This would produce a compilation failure if someone tags something as
__init right? Looks fine to me.
WARNING: multiple messages have this Message-ID (diff)
From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] arm64: efistub: drop __init annotation from handle_kernel_image()
Date: Fri, 29 Jan 2016 16:00:06 +0000 [thread overview]
Message-ID: <20160129160006.GD2611@codeblueprint.co.uk> (raw)
In-Reply-To: <CAKv+Gu9sE4oJrFmSK8sEjTrU8A7k53Hj1S1pTyCqyA5Gsba2Kw@mail.gmail.com>
On Fri, 29 Jan, at 10:36:03AM, Ard Biesheuvel wrote:
> On 28 January 2016 at 23:58, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> >
> > Would it make more sense to #undef __init in one of the arm64 efistub
> > header files? I'm thinking of the case where some poor unsuspecting
> > developer writes a new function and marks it as __init, and we miss it
> > during review.
> >
>
> Yes, I can add it to efistub.h, and make sure it gets included in all the files
>
> Should we #undef it and #define it to a string that is easily grep'ed
> for, so it is easy to find the explanatory comment that goes along
> with it?
> E.g.,
>
> #define __init __init_not_supported_in_efi_stub
This would produce a compilation failure if someone tags something as
__init right? Looks fine to me.
next prev parent reply other threads:[~2016-01-29 16:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 11:07 [PATCH 0/3] arm efi minor fixes Ard Biesheuvel
2016-01-28 11:07 ` [PATCH 1/3] arm64: efistub: drop __init annotation from handle_kernel_image() Ard Biesheuvel
2016-01-28 15:56 ` Will Deacon
[not found] ` <1453979254-25374-2-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-01-28 22:58 ` Matt Fleming
2016-01-28 22:58 ` Matt Fleming
[not found] ` <20160128225809.GF2571-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-01-29 9:36 ` Ard Biesheuvel
2016-01-29 9:36 ` Ard Biesheuvel
[not found] ` <CAKv+Gu9sE4oJrFmSK8sEjTrU8A7k53Hj1S1pTyCqyA5Gsba2Kw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-29 16:00 ` Matt Fleming [this message]
2016-01-29 16:00 ` Matt Fleming
[not found] ` <20160129160006.GD2611-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-01-29 16:03 ` Ard Biesheuvel
2016-01-29 16:03 ` Ard Biesheuvel
[not found] ` <CAKv+Gu96tdf8ZrGHDi_YKacsRF_b336Nu4Anh61j4u3Lg18BHg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-02 11:08 ` Matt Fleming
2016-02-02 11:08 ` Matt Fleming
[not found] ` <20160202110821.GB2642-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-02-02 11:09 ` Ard Biesheuvel
2016-02-02 11:09 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_rvLMFF9ssdY4GCWpdcOwaXVsaCvBTYG30NS0zw5xBWw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-03 15:19 ` Matt Fleming
2016-02-03 15:19 ` Matt Fleming
[not found] ` <20160203151927.GJ2597-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-02-03 15:21 ` Ard Biesheuvel
2016-02-03 15:21 ` Ard Biesheuvel
2016-01-28 11:07 ` [PATCH 2/3] arm64: vmlinux.lds.S: handle .init.rodata.xxx and .init.bss sections Ard Biesheuvel
2016-01-28 15:57 ` Will Deacon
[not found] ` <1453979254-25374-3-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-01-28 22:59 ` Matt Fleming
2016-01-28 22:59 ` Matt Fleming
2016-01-28 11:07 ` [PATCH 3/3] efi: arm-init: use read-only early mappings Ard Biesheuvel
2016-01-28 15:53 ` [PATCH 0/3] arm efi minor fixes Mark Rutland
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=20160129160006.GD2611@codeblueprint.co.uk \
--to=matt-mf/unelci9gs6ibeejttw/xrex20p6io@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@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 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.