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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to