[RFC] SystemTap future direction

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

Hi,

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

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)

Anyway, I think it's the time to discuss how we can get over this
situation and which is the feature direction of SystemTap together.
Since we already has many users, we are responsible to support them.

I'd like to suggest some directions here;

- Merge runtime and module-source generator into linux kernel.
 This will requires rewriting whole of systemtap code from C++ to
 C or other LL (perl or python)

- Port SystemTap on the perf/ftrace and extend perf/ftrace to support
 extend handlers which provided by modules.

- Port SystemTap on the perf/ftrace but drop embedded-C support.
 This will enhance perf/ftrace to support enough flexible data
 filter/modifier (including fault injection feature). In this case,
 SystemTap scripts will handle the data in user-space (not on-line).

- Or, just do nothing and wait for kernel  maintainers choking
 our necks...

I don't think the last one is the best one.
What would you think about that?


BTW, does no one attend to LinuxCon 2010 in Boston?
I'll be there next week...

Best Regards,

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