This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
kernel summit session on systemtap
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: systemtap at sources dot redhat dot com
- Date: Wed, 17 Sep 2008 10:41:15 -0400
- Subject: kernel summit session on systemtap
Hi -
Yesterday morning, we had a 90-minute session on topics touching
systemtap. Though there were several serious concerns raised, it went
better than I had expected.
Here are some things we need to work more on:
- Making it dead easy for kernel guys to build and use the thing.
It's hard to say how what problems they run into since only the rare
bug report gets sent, but some possibilities could be:
- be able to work against an un-installed kernel build tree
- add buildid checking
- bundle elfutils sources for the distro-challenged :-)
- other ideas, please!
- It's time to really improve & shrink debuginfo. Enough said.
- We need to test constantly agaist linus/linux-next type git trees,
at least to confirm that the runtime works. There is a perception
that it breaks often, and this in turn is driving the impulse to
pull the runtime into the kernel. If we can more aggressively
handle the problem, the impulse would die off. We could still of
course push some of the runtime upstream, but that could happen for
stronger technical reasons rather than kneejerks. Linus hinted at
going through akpm since he's such a pushover :-)
- Stability. Kernel crashes are an instant and long-lasting turn-off,
even to the point of mean laughter. We need to urgently and deeply
stress-test and robustify our kernel-side foundations (kprobes,
utrace, uprobes, runtime).
Here are some areas I am no longer that worried about:
- The general approach of synthesized modules vs. bytecode
interpeters. This dtrace-favouring marketing canard was brought up
yet again ("systemtap is unstable because ...", but before I got a
chance to rebut, Linus himself said that VMs are not a good answer
either. With the above "foundation robustness" problem improved,
there will be evidence that should satisfy more skeptics.
- Markers. There was a concensus that the kernel needs more of them.
Well, there was quite some indecision over who should champion them,
but a tasteful set of some dozens should be uncontroversial. A good
start to prime the pump would be some baby kernel-side tool that
connects markers to an existing tracing channel, perhaps one little
piece of lttng.
- The tool's generality. Linus is rightly skeptical of a tool that
aims too high and turns out to be too hard to use. (I believe
"piece of shit" was his shock-value opening comment. :-) He`s also
annoyed at the continuing proliferation of tracing widgets. There
was a short spurt of support for increasing the reach of tools like
"latencytop" (speculating that it "solves the problems for 80% of
people"), but then many people spoke of important problems that only
a broader tool can address.
- FChE