Messages in this thread | | | Date | Thu, 29 Jan 2009 15:31:20 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] tracer for sys_open() - sreadahead |
| |
* Frédéric Weisbecker <fweisbec@gmail.com> wrote:
> 2009/1/29 Ingo Molnar <mingo@elte.hu>: > > > > * Frederic Weisbecker <fweisbec@gmail.com> wrote: > > > >> On Tue, Jan 27, 2009 at 11:43:03PM +0100, Frederic Weisbecker wrote: > >> > On Tue, Jan 27, 2009 at 12:08:04PM -0800, Kok, Auke wrote: > >> > > > >> > > This tracer monitors regular file open() syscalls. This is a fast > >> > > and low-overhead alternative to strace, and does not allow or > >> > > require to be attached to every process. > >> > > > >> > > The tracer only logs succesfull calls, as those are the only ones we > >> > > are currently interested in, and we can determine the absolute path > >> > > of these files as we log. > >> > > > >> > > Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com> > >> > > >> > > >> > Hi Auke, > >> > > >> > Speaking about a global syscall tracer, I made a patch to trace only the syscalls > >> > with the function-graph-tracer. > >> > > >> > http://lkml.org/lkml/2008/12/30/267 > >> > > >> > Its approach and purpose is different than a tracer dedicated only to syscalls. > >> > The function graph tracer traces execution graph of the functions and is more about > >> > execution time spent and code flow whereas a syscall tracer can provide more specific > >> > informations about syscalls. > >> > > >> > So both are not overlaping. > >> > > >> > But the low level part of my patch creates a thread flag _TIF_SYSCALL_TRACE which triggers > >> > >> s/_TIF_SYSCALL_TRACE/_TIF_SYSCALL_FTRACE > > > >> > Once we have it, I think a syscall tracer can be fed with new syscalls > >> > events through several patch iterations, starting with the open and > >> > close one :-) > >> > > >> > Are you ok with that? > >> > > >> > Steven, Ingo, do you agree? > > > > yes. We definitely need this on the asm syscall level, to not contaminate > > hundreds of syscalls with tracepoints. > > > > Auke's sys_open() plugin would be a nice prototype for that concept - but > > in generally it would be useful to be able to augment kernel tracer output > > with all syscall events that occur. > > > > The output would be something like a slimmed-down strace, but for the > > whole kernel and not tied to ptrace semantics (which are crippling). > > > > Would you be interested in extending your syscall tracing concept with > > those bits and would you be interested in integrating Auke's plugin into > > that > > > > Ingo > > > Several people talked me about utrace and gave some examples about it in > this discussion. The Api is very convenient to fetch syscall numbers, > arguments and return values. And the hooks are done in the generic core > code, so it is arch independent. > > The only drawback I can see is that it is not yet merged upstream, in > need of in-kernel users. If it only depends on this condition, we could > be these users... > > What do you think?
sure - how do the minimal bits/callbacks look like which enable syscall tracing?
Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |