Re: [PATCH 5/5] tracing/ftrace: Introduce the big kernel lock tracer

["Frédéric Weisbecker" <fweisbec@gmail.com>]

2008/10/24 Frank Ch. Eigler <fche@redhat.com>:
> That's what we do with the systemtap script, where kernel "handling"
> consists of "running the machine code".
>
>> But have the user application interface be very simple, and perhaps
>> even use perl or python.
>
> perl and python are pretty big procedural languages, and are not
> easily compiled down to compact & quickly executed machine code.  (I
> take it no one is suggesting including a perl or python VM in the
> kernel.)  Plus, debugger-flavoured event-handling programming style
> would not look nearly as compact in perl/python as in systemtap, which
> is small and domain-specific.
>
> - FChE
>

Actually what I thought is a style like this (Python like):

probe = Systemtap.probeFunc("lock_kernel")
probe.captureUtime("utime"))
probe.captureBacktrace("trace")
probe.trace()

For an obvious set of batch work like that, that could be possible,
perhaps even easy
to implement an Api...
When the object calls trace(), the userspace Systemtap analyse the list
of work to do and then translate into commands in kernel space.

And the script could wait for events and then do its own processing
with the captured events
(do some operations on delays, on output....).

for event in probe.getEvent(): #blocking
    print event["utime"]
    trace = event["trace"] #Systemtap.trace object with specific
fields and a default string repr
    print trace

It would be interpreted by Python itself, and you just have to capture
commands and works
sent through Api. Then, when the kernel has something to give, you
just have to place it in the
appripriate object and transmit it to the script which is waiting.
Processing and output with the data are done by the python script.
So actually, the python script only needs to ask you what data to
capture. It's its own responsability to
do wathever it wants with.

What do you think?