|| ||fche-AT-redhat.com (Frank Ch. Eigler) |
|| ||Masami Hiramatsu <masami.hiramatsu.pt-AT-hitachi.com> |
|| ||Re: [RFC] SystemTap future direction |
|| ||Wed, 04 Aug 2010 12:32:28 -0400|
|| ||systemtap-AT-sources.redhat.com, Satoshi Oshima <satoshi.oshima.fk-AT-hitachi.com>|
|| ||Article, Thread
> 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 is unfortunate, but is in a way useful evidence about what sorts
of effects we can expect from further outreach efforts. You and
Srikar have spent at least a year working on mini-stap functionality
for the benefit of the perf side of the house, and yet the amount of
goodwill offered in return is ... where?
> This means that if we succeed to merge uprobes into kernel,
> SystemTap can't use uprobes itself.
Well, there are always various social and technical measures to work
around gratuitious obstacles.
> Even worse, if someone tries to remove kprobes' module support, that
> could shake the foundation of SystemTap.
It is hard to imagine someone deliberately hurting linux users that way.
> 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. [...]
Or #3, coming up with one more substantial in-tree uprobes example
than the one hch instructed srikar to drop.
> 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)
More concretely, to rewrite and LKML-code-standarize the lot, but
retain current architecture? Do you sense that there's any interest
in this sort of solution by Linus?
> - Port SystemTap on the perf/ftrace and extend perf/ftrace to support
> extend handlers which provided by modules.
More concretely, to make a version of systemtap that instead of
generating stand-alone kernel modules that operate independently of
perf/etc., that they be bound to perf event sources & infrastructure?
But retain the power of our system by still executing arbitrary
generated code from those callbacks? Do you sense that there's any
interest in this sort of solution by the perf people?
Now if we're talking about a module-encased bytecode interpreter / JIT
rich enough to encompass our runtime/language features, I have some
interest in this sort of solution, whether coupled or decoupled from
perf. But this is a large amount of effort. But we're tempted.
> - 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).
I get the sense the perf people believe they are on this course
already, without needing any help.
> - Or, just do nothing and wait for kernel maintainers choking
> our necks...
I don't think the situation is in fact deteriorating. We're shipping
decent releases, growing our user base, within and without the kernel
developer community, and still have plenty of major feature areas to
work on. We have not seen regressive LKML obstructions, though
admittedly that is a low standard when it comes to serving the
to post comments)