Re: patches to actually use markers?

Hi -

On Fri, Nov 16, 2007 at 03:35:39PM -0500, Mathieu Desnoyers wrote:
> [...]
> > I see.  Yes, per-systemcall markers would be welcome by our group, and
> > ones not dependent on TIF_TRACE or whatnot even more so.  But were
> > trying not to get too optimistic.
> 
> I use per-systemcall markers for the principally useful systemcalls, but
> I also instrument syscall_trace() to get all the other syscalls (new
> ones, etc..).

So then some system calls would get duplicate trace reports, and some
would not get arguments at all?  Does not sound ideal.

> I add my own TIF_KERNEL_TRACE, which is a thread flag enabled in
> each and every thread when tracing is active.  [...]

Who has responsibility to manage this flag?  Would it be reference
counted, so that e.g.  two ltt and a third systemtap script all hook
up to these markers, the flag will will stay set?  It would be nice to
measure the impact of ordinary, unconditional markers in the
system-call functions.

> > If "we" is a marker callback function that is given the system call
> > number, it can be taught.  This is the sort of thing we do currently
> > in systemtap script code based upon kprobes.
> 
> Yeah.. but I fear that within the kernel it can become quickly very
> ugly.

It's an inherent tradeoff between a small generic hook versus many
specialized hooks.  Look how the audit system deals with decoding
syscalls.  It's not THAT bad.

- FChE