This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] SystemTap future direction
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: systemtap at sources dot redhat dot com, Satoshi Oshima <satoshi dot oshima dot fk at hitachi dot com>
- Date: Thu, 05 Aug 2010 21:33:34 +0900
- Subject: Re: [RFC] SystemTap future direction
- References: <4C58F852.7030103@hitachi.com> <87iq3qem1i.fsf@basil.nowhere.org>
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