All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
	Jiaying Zhang <jiayingz@google.com>,
	Martin Bligh <mbligh@google.com>
Subject: Re: [RFC][PATCH 1/2] tracing/ftrace: syscall tracing infrastructure
Date: Mon, 9 Mar 2009 21:40:14 +0100	[thread overview]
Message-ID: <20090309204013.GB5010@nowhere> (raw)
In-Reply-To: <20090308162444.GG19658@elte.hu>

On Sun, Mar 08, 2009 at 05:24:44PM +0100, Ingo Molnar wrote:
> 
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > +static const struct syscall_trace_entry syscall_trace_entries[] = {
> > +	/* For open, the first argument is a string, hence the given mask */
> > +	[SYSCALL_TRACE_OPEN]	= SYS_TRACE_ENTRY(open, 3, 0x1),
> > +	[SYSCALL_TRACE_CLOSE]	= SYS_TRACE_ENTRY(close, 1, 0),
> > +	[SYSCALL_TRACE_READ]	= SYS_TRACE_ENTRY(read, 3, 0),
> > +	[SYSCALL_TRACE_WRITE]	= SYS_TRACE_ENTRY(read, 3, 0),
> > +};
> 
> s/read/write in the last entry i guess.
> 
> But i think the whole concept of duplicating the syscall table 
> is the wrong way around.
> 
> Note that we dont have to build this information at all - in 
> 2.6.29-rc1 all syscalls got wrapper macros:
> 
>  SYSCALL_DEFINE1(nice, int, increment)
>  SYSCALL_DEFINE2(sched_setparam, pid_t, pid, struct sched_param __user *, param)
>  SYSCALL_DEFINE3(sched_setaffinity, pid_t, pid, unsigned int, len,
>                  unsigned long __user *, user_mask_ptr)
> 
> We also have the syscall table itself.
> 
> So what we can do: by changing the SYSCALL_DEFINEX() macros we 
> can emit the following information into a table:
> 
>   (syscall_fn_address, syscall_name_string, #of arguments, array 
>    of argument names and type sizeof()s)
> 
> then during bootup we can match up the sys_call_table[] to the 
> secondary table we built, so that we can order the secondary 
> table based on syscall NR. 99% of the syscalls will match up 
> just fine.
> 
> 	Ingo

Yes, I didn't know the SYSCALL_DEFINEx() macro until Peter told me.
That's indeed a much better way to proceed, I will look at all that.


Thanks!


  reply	other threads:[~2009-03-09 20:40 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-07  4:52 [RFC][PATCH 0/2] Syscalls tracing Frederic Weisbecker
2009-03-07  4:52 ` [RFC][PATCH 1/2] tracing/ftrace: syscall tracing infrastructure Frederic Weisbecker
2009-03-07  7:49   ` Frederic Weisbecker
2009-03-09 13:52     ` Steven Rostedt
2009-03-09 20:47       ` Frederic Weisbecker
2009-03-10  0:52         ` Steven Rostedt
2009-03-10 10:08           ` Frederic Weisbecker
2009-03-08 16:24   ` Ingo Molnar
2009-03-09 20:40     ` Frederic Weisbecker [this message]
2009-03-09 13:44   ` Steven Rostedt
2009-03-09 20:42     ` Frederic Weisbecker
2009-03-13  4:27   ` [tip:tracing/syscalls] tracing/ftrace: syscall tracing infrastructure, basics Frederic Weisbecker
2009-03-16 19:36   ` [RFC][PATCH 1/2] tracing/ftrace: syscall tracing infrastructure Masami Hiramatsu
2009-03-16 20:15     ` Frederic Weisbecker
2009-03-16 20:38       ` Masami Hiramatsu
2009-03-16 21:45         ` Mathieu Desnoyers
2009-03-16 22:18           ` Frank Ch. Eigler
2009-03-16 23:46             ` Frederic Weisbecker
2009-03-23 16:42             ` Mathieu Desnoyers
2009-03-23 16:52               ` Frank Ch. Eigler
2009-03-23 17:03                 ` Mathieu Desnoyers
2009-03-17  5:24           ` Oleg Nesterov
2009-03-17 16:00             ` Mathieu Desnoyers
2009-03-19 10:34               ` Roland McGrath
2009-03-23 17:33                 ` Mathieu Desnoyers
2009-03-07  4:53 ` [RFC][PATCH 2/2] tracing/x86: basic implementation of syscall tracing for x86-64 Frederic Weisbecker
2009-03-13  4:27   ` [tip:tracing/syscalls] tracing/x86: basic implementation of syscall tracing for x86 Frederic Weisbecker
2009-03-13 16:09   ` [tip:tracing/syscalls] tracing/syscalls: support for syscalls tracing on x86, fix Ingo Molnar
2009-03-13 16:32   ` [RFC][PATCH 2/2] tracing/x86: basic implementation of syscall tracing for x86-64 Mathieu Desnoyers
2009-03-13 16:37     ` Ingo Molnar
2009-03-13 16:50       ` Mathieu Desnoyers
2009-03-15  4:44         ` Ingo Molnar
2009-03-15 15:16           ` Frederic Weisbecker
2009-03-15 19:22           ` Mathieu Desnoyers
2009-03-07 12:15 ` [RFC][PATCH 0/2] Syscalls tracing Peter Zijlstra
2009-03-07 16:02   ` Frederic Weisbecker
2009-03-08 11:24     ` Frederic Weisbecker
2009-03-08 11:28       ` Frederic Weisbecker
2009-03-07 20:26 ` Frank Ch. Eigler
2009-03-07 21:53   ` Frederic Weisbecker

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=20090309204013.GB5010@nowhere \
    --to=fweisbec@gmail.com \
    --cc=jiayingz@google.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mbligh@google.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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.