From: michael@ellerman•id.au (Michael Ellerman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file
Date: Tue, 30 Jun 2015 13:29:05 +1000 [thread overview]
Message-ID: <1435634945.24866.2.camel@ellerman.id.au> (raw)
In-Reply-To: <5581BCD0.2040405@linaro.org>
On Wed, 2015-06-17 at 14:30 -0400, David Long wrote:
> On 06/16/15 09:17, Rob Herring wrote:
> > On Mon, Jun 15, 2015 at 11:42 AM, David Long <dave.long@linaro•org> wrote:
> >>
> >> #define REG_OFFSET_NAME(r) \
> >> {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
> >> #define REG_OFFSET_END {.name = NULL, .offset = 0}
> >
> > Can't you also move these? ARM is complicated with the "ARM_"
> > prefixing, but the others appear to be the same. Maybe you can remove
> > the prefix or redefine the macro for ARM.
>
> That would mandate that all the architecture-specific pt_regs structures
> would have to use a top-level named field for each named register.
Why does it mandate that?
See eg. powerpc where we use REG_OFFSET_NAME for the top-level named fields and
then a different macro for the array elements:
#define REG_OFFSET_NAME(r) {.name = #r, .offset = offsetof(struct pt_regs, r)}
#define GPR_OFFSET_NAME(num) \
{.name = STR(gpr##num), .offset = offsetof(struct pt_regs, gpr[num])}
static const struct pt_regs_offset regoffset_table[] = {
GPR_OFFSET_NAME(0),
GPR_OFFSET_NAME(1),
GPR_OFFSET_NAME(2),
GPR_OFFSET_NAME(3),
...
REG_OFFSET_NAME(nip),
REG_OFFSET_NAME(msr),
So I don't see why REG_OFFSET_NAME couldn't be common.
cheers
next prev parent reply other threads:[~2015-06-30 3:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 16:42 [PATCH 0/2] Consolidate redundant register/stack access code David Long
2015-06-15 16:42 ` [PATCH 1/2] Move the pt_regs_offset struct definition from arch to common include file David Long
2015-06-16 13:17 ` Rob Herring
2015-06-17 18:30 ` David Long
2015-06-30 3:29 ` Michael Ellerman [this message]
2015-07-22 4:46 ` David Long
2015-07-22 5:11 ` Michael Ellerman
2015-07-22 13:30 ` David Long
2015-06-19 4:19 ` Michael Ellerman
2015-06-19 14:12 ` David Long
2015-06-19 16:58 ` Kees Cook
2015-06-26 18:35 ` David Long
2015-06-23 3:32 ` Michael Ellerman
2015-06-23 13:48 ` David Long
2015-06-24 4:07 ` Michael Ellerman
2015-06-24 13:49 ` David Long
2015-06-15 16:42 ` [PATCH 2/2] Consolidate redundant register/stack access code David Long
2015-06-18 18:13 ` rkuo
2015-06-15 20:44 ` [PATCH 0/2] " Kees Cook
2015-06-15 20:58 ` David Long
2015-06-16 8:12 ` Martin Schwidefsky
2015-06-16 17:39 ` Will Deacon
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=1435634945.24866.2.camel@ellerman.id.au \
--to=michael@ellerman$(echo .)id.au \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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