From: Harvey Harrison <harvey.harrison@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] x86: Use v8086_mode helper, trivial unification
Date: Thu, 17 Jan 2008 15:26:29 -0800 [thread overview]
Message-ID: <1200612389.5724.63.camel@brick> (raw)
In-Reply-To: <478FDE76.3070309@zytor.com>
On Thu, 2008-01-17 at 18:02 -0500, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> > Use v8086_mode inline in fault_32.c, no functional change
> > also ifdef the section for 32-bit only and add to fault_64.c
>
> The #ifdef is unnecessary, since v8086_mode() is now a constant zero on
> x86-64. gcc will remove the if clause.
>
Sorry, missed that detail in ptrace.h, I notice now.
Is there some better way this could be organized, would the following
be an improvement, as opposed to two long ifdef sections?
Patch will follow if you think it's a good idea.
static inline int user_mode(struct pt_regs *regs)
{
#ifdef CONFIG_X86_32
return (regs->cs & SEGMENT_RPL_MASK) == USER_RPL;
#else
return !!(regs->cs & 3);
#endif
}
static inline int user_mode_vm(struct pt_regs *regs)
{
#ifdef CONFIG_X86_32
return ((regs->cs & SEGMENT_RPL_MASK) |
(regs->flags & VM_MASK)) >= USER_RPL;
#else
return user_mode(regs);
#endif
}
static inline int v8086_mode(struct pt_regs *regs)
{
#ifdef CONFIG_X86_32
return (regs->flags & VM_MASK);
#else
return 0;
#endif
}
/* OK, maybe this should just be deleted, and use
regs->ip directly in code*/
static inline unsigned long instruction_pointer(struct pt_regs *regs)
{
return regs->ip;
}
/* OK, maybe this should just be deleted, and use
regs->bp directly in code*/
static inline unsigned long frame_pointer(struct pt_regs *regs)
{
return regs->bp;
}
static inline unsigned long stack_pointer(struct pt_regs *regs)
{
#ifdef CONFIG_X86_32
return (unsigned long)regs;
#else
return regs->sp;
#endif
}
/* still need a define here, as one is long and one is unsigned long.
* but this is another target for unification I guess. */
#define regs_return_value(regs) ((regs)->ax)
Harvey
next prev parent reply other threads:[~2008-01-17 23:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-17 23:04 [PATCH] x86: Use v8086_mode helper, trivial unification Harvey Harrison
2008-01-17 23:02 ` H. Peter Anvin
2008-01-17 23:26 ` Harvey Harrison [this message]
2008-01-18 0:59 ` H. Peter Anvin
2008-01-18 1:14 ` Harvey Harrison
2008-01-18 1:14 ` H. Peter Anvin
2008-01-18 1:23 ` Harvey Harrison
2008-01-18 1:15 ` Harvey Harrison
2008-01-18 1:37 ` Roland McGrath
2008-01-18 1:36 ` H. Peter Anvin
2008-01-18 2:02 ` Harvey Harrison
2008-01-18 2:21 ` Harvey Harrison
2008-01-18 3:35 ` H. Peter Anvin
2008-01-18 4:28 ` [PATCH] x86: Rename stack_pointer to kernel_trap_sp Harvey Harrison
2008-01-18 9:07 ` Ingo Molnar
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=1200612389.5724.63.camel@brick \
--to=harvey.harrison@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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