Re: [RFC] ktap: Another dynamic tracing tool for Linux

["Frank Ch. Eigler" <fche@redhat.com>]

Hi -

bookjovi wrote:

> >> [...]
> >> ktap use lua language syntax and bytecode as initial implementation,
> >
> > Interesting approach.  I recall we considered it way back when, but
> > rejected it for a couple of reasons, including the at-the-time
> > perceived unwelcomeness of a serious bytecode interpreter within the
> > kernel.

> [...]  Obviously, the bytecode design is the biggest differences
> with systemtap.  [...]  many Linux box doesn't deliver with gcc,
> this is very common in embedded device, even there installed gcc,
> but it's hard(impossible) to get matched kernel source.  [...]

Right, that is a strong attraction.


> [...]  On clear that, ktap is not a replacement to systemtap, it's
> supplementation.

FWIW, it would be reasonable to have systemtap emit bytecodes as an
alternative backend.  All that has been lacking is a powerful and
pervasive enough interpreter.  The script language is not tied to its
implementation via C code generation.


That reminds me of your item #4 on your ktap-systemtap comparison:

> 4). ktap is safe, whatever you doing in script file, you will never
> crash your kernel.

This is roughly as true for systemtap as for anything else.  The
scripts are constrainted to be safe.  Kernel crashes that occur are
due to occasional bugs in the systemtap runtime library, or down in
the kernel facilities being used.  You would likely encounter both
classes of problems in a kernel-side bytecode interpreter, regardless
of the theoretical safety of the scripting language.  (This is one of
the reasons we've been building out the pure-userspace dyninst-based
systemtap backend.)


> I will try to make ktap develop progress more faster, and make ktap
> source code public available soon.

Yes, please.  (RFC/experimental code need not be complete before
posting; why not develop straight on github?)


- FChE