[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071125222205.GA1597@infradead.org>
Date: Sun, 25 Nov 2007 22:22:05 +0000
From: Christoph Hellwig <hch@...radead.org>
To: Roland McGrath <roland@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 01/27] ptrace: arch_has_single_step
On Sun, Nov 25, 2007 at 01:55:07PM -0800, Roland McGrath wrote:
> This defines the new macro arch_has_single_step() in linux/ptrace.h, a
> default for when asm/ptrace.h does not define it. It declares the new
> user_enable_single_step and user_disable_single_step functions.
> This is not used yet, but paves the way to harmonize on this interface
> for the arch-specific calls on all machines.
Why should arch_has_single_step be a function-like macro? I can't thing
of a case were this wouln't be a compile-time constant. And given that
this is hopefully a transitionary ifdef because eventually all architectures
would use the generic code I'd prefer ifdefs in the code that clearly mark
this as transitional in this case.
> +static inline void user_enable_single_step(struct task_struct *task)
> +static inline void user_disable_single_step(struct task_struct *task)
And I don't think these should be provided at all as generic stubs. If
an arch doesn't use the generic code it simply shouldn't compile the
code using this.
Whats the reason for the user_ prefix btw, most architectures seems to
have these functions already anyway, just without the user_ prefix.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists