Re: Customization of LKET

[Li Guanglei <guanglei at cn dot ibm dot com>]

Frank Ch. Eigler ??:
> Li Guanglei <guanglei@cn.ibm.com> writes:
>
> > I had a talk with Jose last week and we think it would be useful to
> > make the user able to append extra data on the trace at script
> > level.
>
> It was this kind of flexibility in mind that I proposed the "compiled"
> binary tracing alternative in
> <http://sourceware.org/ml/systemtap/2006-q1/msg00277.html>.  It was
> more recently been mentioned indirectly by Tom in
> <http://sourceware.org/ml/systemtap/2006-q2/msg00070.html>.  This
> would be a more general solution to flexible & incremental
> construction of binary trace records.

Thanks. I will think about it.

> > Of course the user could modify the tapsets in tapset/LKET to let
> > _lket_trace() log more data. But it's not a convenient way. It's
> > obvious that a function like printf() at script level is better, i.e:
> > [...]
> >     lket_trace_extra("%4b", $numa_node)
> > [...]
> > #define _lket_trace_extra(fmt, args...)  do {\
> >         _stp_printf("%1b%2n%0s"fmt, LKET_PKT_USER, fmt, args);\
> > } while(0)
>
> I must say I don't much like this approach.  Is the only point
> here to add "LKET_PKT_USER" as a constant byte into the printf?

lket_trace_extra is actually a wrapper around printf. Actually the 
user could directly use printf if he could remember to add 
"%1b%2n%0s". LKET_PKT_USER and %2n is used by post-processing app to 
properly found the boundary of the record. %0s(fmt) is also used by 
post-processing app to correctly decode the user appended trace data.

So the reason I use lket_trace_extra() is that I want to hide 
something from the user since I can't expect everyone following the 
rules of adding extra data.

But I have to confess that it seems a waste to introduce such a new 
function into systemtap's translator. It seems too application 
specific. A more generic trace facilities at script level is more 
meaningful.

Before we find the final solution, I think I can use a temp solution, 
that is:
  _lket_trace() add a magic number(4 or 8 bytes) at the beginning of 
record to specify the boundary of every record.
  The user can just use printf to add extra data, no LKET_PKT_USER 
flag and %2n is needed. lket-b2a can simply dump all the extra data in 
hex mode, or we introduce a function: register_eventhook(GRPID:long, 
HOOKID:long, Format:string) for user to register the format of his 
extra data. But I think the later seems better.
  I am not sure this is a good idea but at least it won't need to 
modify translator :-)

I am thinking of revert my changes of lket_trace_extra() to translator.

> > I modified systemtap to make it able to support lket_trace_extra at
> > script level. [...]
>
> Modify LKET tapset sources at will, but please consider
> application-specific changes to the translator proper as possibly
> controversial, and allow more time for review.
>
>
> > [...]
> > probe addevent.pagefault
> > {
> >    lket_trace_extra("%4b%0s", $numa_node, backtrace())
> > }
> > But there is trouble that MAXSTRINGLEN is defined as 128 so backtrace
> > string will be truncated. Simply raising MAXSTRINGLEN will cause a lot
> > of waste of memory.
>
> It would be wise to test that assumption.  Remember that the
> translator uses a statically allocated array for local values like
> string temporaries.  Temporaries for adjacent statements are overlaid.
> The overall size of the context structure may be small enough even
> with a quadrupled MAXSTRINGLEN for it to work out fine.  Test it and
> see.

I tested using a simple script:
function foo()
%{
        _stp_printf("%d\n", sizeof(struct context));
%}
probe addevent.syscall.*
{
        printf("%s\n", "aa")
        foo()
}

it shows that the size of context will increase from 6608 to 51408  if 
MAXSTRINGLEN is defined as 1024. Seems acceptable, right?

> - FChE