All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
	lkml <linux-kernel@vger.kernel.org>,
	systemtap <systemtap@sources.redhat.com>,
	kvm <kvm@vger.kernel.org>,
	DLE <dle-develop@lists.sourceforge.net>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Roland McGrath <roland@redhat.com>,
	linux-arch@vger.kernel.org
Subject: Re: [PATCH -tip v8 5/7] x86: add pt_regs register and stack access APIs
Date: Sat, 30 May 2009 10:48:51 -0400	[thread overview]
Message-ID: <4A214753.8080005@redhat.com> (raw)
In-Reply-To: <20090530081303.GB15755@infradead.org>

Hi Christoph,

Thank you for review.

Christoph Hellwig wrote:
> You might want to run this past linux-arch to make sure this is suitable
> for other architectures.

Frankly, I'm not sure about linux-arch, could you explain it?
Anyway, I'm interested in that idea.

>> --- a/arch/x86/include/asm/ptrace.h
>> +++ b/arch/x86/include/asm/ptrace.h
>> @@ -7,6 +7,7 @@
>>  
>>  #ifdef __KERNEL__
>>  #include <asm/segment.h>
>> +#include <asm/page_types.h>
>>  #endif
> 
> I really wonder if we should split asm/ptrace.h into one file
> just defining pt_regs both for userspace and the kernel, and one with
> all kinds of register access helpers and maybe another one for the
> ptrace architecture interface.

Agreed, pt_regs is used more broadly than ptrace itself in kernel.

> Unforuntately we would have to keep the ptrace.h name for the one
> carrying pt_regs as it's exposed to userland.

Perhaps, we should split pt_regs from ptrace.h, like as ptrace-regs.h.

>> +static inline unsigned long get_register(struct pt_regs *regs, unsigned offset)
>> +{
> 
> I woner if all these names aren't a bit generic.  Shoud we maybe add a
> regs_ prefix to make it clear it operates on a pt_regs register set?

Indeed.

> Also some kerneldoc documentation for all these helpers would be nice.

Sure.

>> +/* Get Nth argument at function call */
>> +static inline unsigned long get_argument_nth(struct pt_regs *regs, unsigned n)
>> +{
>> +#ifdef CONFIG_X86_32
>> +#define NR_REGPARMS 3
> 
> I think completely separate version for 32 vs 64 bit for this one would
> be cleaner.

Agreed,

> 
>> +	if (n < NR_REGPARMS) {
>> +		switch (n) {
>> +		case 0: return regs->ax;
>> +		case 1: return regs->dx;
>> +		case 2: return regs->cx;
>> +		}
> 
> Normal kernel style would be
> 
> 		switch (n) {
> 		case 0:
> 			return regs->ax;
> 		case 1:
> 			return regs->dx;
> 		case 2:
> 			return regs->cx;
> 		}

Oops, thanks,

> 
>> +#define REG_OFFSET(r) offsetof(struct pt_regs, r)
>> +#define REG_OFFSET_NAME(r) {.name = #r, .offset = REG_OFFSET(r)}
>> +#define REG_OFFSET_END {.name = NULL, .offset = 0}
> 
> At least the REG_OFFSET macro seems superflous to me.
> 

Exactly.

Thank you again!

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com

  reply	other threads:[~2009-05-30 14:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-29  0:03 [PATCH -tip v8 0/7] tracing: kprobe-based event tracer and x86 instruction decoder Masami Hiramatsu
2009-05-29  0:03 ` Masami Hiramatsu
2009-05-29  0:03 ` [PATCH -tip v8 1/7] x86: instruction decoder API Masami Hiramatsu
2009-05-29  0:03   ` Masami Hiramatsu
2009-05-29  0:03 ` [PATCH -tip v8 2/7] x86: x86 instruction decoder build-time selftest Masami Hiramatsu
2009-05-29  0:03   ` Masami Hiramatsu
2009-05-29  0:03 ` [PATCH -tip v8 3/7] kprobes: checks probe address is instruction boudary on x86 Masami Hiramatsu
2009-05-29  0:03 ` [PATCH -tip v8 4/7] kprobes: cleanup fix_riprel() using insn decoder " Masami Hiramatsu
2009-05-29  0:03 ` [PATCH -tip v8 5/7] x86: add pt_regs register and stack access APIs Masami Hiramatsu
2009-05-30  8:13   ` Christoph Hellwig
2009-05-30 14:48     ` Masami Hiramatsu [this message]
2009-06-01 23:40     ` Ingo Molnar
2009-05-29  0:03 ` [PATCH -tip v8 6/7] tracing: ftrace dynamic ftrace_event_call support Masami Hiramatsu
2009-05-30  3:23   ` Steven Rostedt
2009-05-29  0:03 ` [PATCH -tip v8 7/7] tracing: add kprobe-based event tracer Masami Hiramatsu
2009-05-29  0:03   ` Masami Hiramatsu
2009-05-30  3:29   ` Steven Rostedt
2009-05-30  4:11   ` Steven Rostedt
2009-05-30 13:15     ` Masami Hiramatsu
2009-05-30  8:15   ` Christoph Hellwig
2009-05-30 14:38     ` Masami Hiramatsu
2009-05-30  8:05 ` [PATCH -tip v8 0/7] tracing: kprobe-based event tracer and x86 instruction decoder Christoph Hellwig
2009-05-31 13:43   ` Masami Hiramatsu
2009-05-31 13:43     ` Masami Hiramatsu

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=4A214753.8080005@redhat.com \
    --to=mhiramat@redhat.com \
    --cc=ananth@in.ibm.com \
    --cc=dle-develop@lists.sourceforge.net \
    --cc=fweisbec@gmail.com \
    --cc=hch@infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=roland@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=systemtap@sources.redhat.com \
    /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.