Re: [RFC] SystemTap future direction

[Andi Kleen <andi at firstfloor dot org>]

Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> writes:

> As you may know (of course I Cc'd discussion on LKML), Ingo and
> Christoph said that (at least) uprobes (but also kprobes) should
> not support out-of-tree module.

They don't necessarily have the last word on this. Last word would be 
Linus.

> This means that if we succeed to merge uprobes into kernel,
> SystemTap can't use uprobes itself. Even worse, if someone tries
> to remove kprobes' module support, that could shake the foundation
> of SystemTap.

There are already kprobes modules in tree I believe, which
would be broken too.

Also traditionally patches that broke a widely used free software
out of tree module haven't been merged in the past.

> At least, to add support kmodules to uprobes, I think we have two
> options, one is pushing systemtap itself and useful scripts into
> kernel tree, or the other is finding very useful use-case of *probes
> which requires out-of-tree module. (But the first one is hard because
> Linus hates C++, and systemtap is too huge to push into the kernel)

One thing that might work is to move at least larger parts of the
systemtap kernel runtime library into the kernel tree and then have
a couple of example modules written in C that exercise all the
interfaces (and ideally do something useful in the process too)

In principle even compiler generated modules could be (at least
partially used for this), but I suppose they would need
quite some cleanups. It might be easier to do this with handwritten
C.

Then make sure the compiler output mostly only uses these interfaces.
That is they would need to be useful higher level interfaces, not just an 
thin abstraction layer. I suspect 100% coverage wouldn't be possible
and also the compiler also would use use some other interfaces,
but as long as those are widely used driver interfaces there's
usually no problem.

Basically it's important to have testing coverage in the kernel
for everything that can be used by compiler output (minus guru mode)

This would probably need significant work to clean the library
up for kernel coding style etc. I think some of the code
could be also a lot simplified, especially if there were some
minor changes in the main kernel for this 

(I still don't understand how one needs 1.6kLOC to find a task :)

But you could start in staging with this, so it doesn't require
doing all that work outside mainline.

I think this would also largely fix the problem that systemtap often
breaks with new kernel versions.

For example one of things I really like in systemtap are the 
easy histograms. So if there was a histogram library function
in the kernel I assume that could even find other users.
Now that's only a small part of the code, but there could be more
of this.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.