Re: [RFC] SystemTap future direction

[Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>]

Andi Kleen wrote:
> 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.

Sure, there are some kprobe examples and jprobe users in
kernel tree.

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

I hope so.

>> 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.

Yeah, should be :) Nowadays systemtap generated modules are
very complicated, because of safeness.

> 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 

That's one reason why I've started to push trace-kprobe into
the kernel, which provides a standard interface set for getting
registers, stacks, and memories. I hope finally it could be
shared with systemtap modules.

> (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.

Thanks for a good advice. :) It should be a good candidate to
be included in the kernel.

Thank you,

> 
> -Andi
> 

-- 
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com