Message-ID: <20090307215303.GB5869@nowhere>
Date:	Sat, 7 Mar 2009 22:53:04 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	"Frank Ch. Eigler" <fche@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>, 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 0/2] Syscalls tracing

On Sat, Mar 07, 2009 at 03:26:49PM -0500, Frank Ch. Eigler wrote:
> Frederic Weisbecker <fweisbec@...il.com> writes:
> 
> > Here is a first attempt, quick one-shot, to provide a syscall tracing
> > infrastructure on ftrace.
> 
> Please see also the utrace-based thread syscall/signal/lifecycle.
> tracer I posted a few times, and is just about to be reposted as a
> part of the larger utrace submission.


Yes I've looked at it and as I will explain below, I don't have
any bad feelings against utrace.

 
> System call metadata (name, argument count, and getting fancier from
> there) would be nice to have for other clients too, such as the audit
> subsystem.
> 
> The main drawback of this general approach however is the notion that
> ftrace is the solitary user of system call tracing, thus dedicating
> that new task flag to this purpose.  Therefore, your code has nothing
> like reference counting or sharing; nothing yet to avoid overhead on
> threads that need no tracing, nor to allow more than one tracing
> widget to consume events.  These are the sorts of services that utrace
> provides.
> 
> - FChE


Yes. But it was a first attempt scribbled in one day. I already knew
that a fair amount of bits coming along these patches started on the wrong
way. But that doesn't matter, I just wanted to test the feelings of anyone
interested about the main axis inside:

- having a O(1) access table which stores the number of parameters for each
  syscalls, so that the traced path can be very fast and efficient:
  we know what to save quickly and we only save the relevant bits from
  the path, that said, 1 syscall number (which behaves here as a unique
  identifier key) and its parameters values.

- provide a good way to extract the results. It needs a better and larger work
  on the syscalls metadata. Ie: the string mask is a bit ridiculous, as well as
  the individual callback to display a syscall (because it implies too much work
  and code that can be a lot factorized) but I expect that a discussion about a
  good to produce efficient metadata could born after it.

For example we could have an array of char where the types are encoding using
an enum which describes the types of the parameters.
Depending of these parameters, we can have one callback for each type to display
them. We can also export these metadatas to userspace so that the users are able
to only extract the binary traces and format and give some sense by formatting it
later using the metadas.


Anyway, since this is a first scribbling, there is neither reference count nor
per task tracing granularity :-)

But, that's said, I already expressed my feelings about utrace by the past.
It's a good library, seems easy to use and powerful and I would like to see
it merged.

I don't know what other people think about it. But IMHO, I think it would be good
if you could, for now, make an attempt to sort the only relevant bits to provide
syscalls tracing and submit it.

It would exclude a large part that concerns the signals/fork/exec tracing
which will probably be needed later.

--
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