[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090308162444.GG19658@elte.hu>
Date: Sun, 8 Mar 2009 17:24:44 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Lai Jiangshan <laijs@...fujitsu.com>,
Steven Rostedt <rostedt@...dmis.org>,
Peter Zijlstra <peterz@...radead.org>,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
Jiaying Zhang <jiayingz@...gle.com>,
Martin Bligh <mbligh@...gle.com>
Subject: Re: [RFC][PATCH 1/2] tracing/ftrace: syscall tracing infrastructure
* Frederic Weisbecker <fweisbec@...il.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
--
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