|From:||fche-AT-redhat.com (Frank Ch. Eigler)|
|To:||Masami Hiramatsu <masami.hiramatsu.pt-AT-hitachi.com>|
|Subject:||Re: [RFC] SystemTap future direction|
|Date:||Wed, 04 Aug 2010 12:32:28 -0400|
|Cc:||systemtap-AT-sources.redhat.com, Satoshi Oshima <satoshi.oshima.fk-AT-hitachi.com>|
masami.hiramatsu.pt wrote: > 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 community. - FChE
Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds