Re: Discussion at Linux Foundation Japan Symposium

[Jason Baron <jbaron@redhat.com>]

On Fri, Jan 09, 2009 at 09:48:10PM -0500, Theodore Tso wrote:
> On Tue, Dec 23, 2008 at 07:54:46PM -0500, Masami Hiramatsu wrote:
> > 
> > OK, so I would like to hear your suggestions seriously.
> > (I believe that we know on what we are working).
> > I think it's time to embody action items. Just criticizing can't go
> > things ahead. So, what we can do for you?
> > 
> > - Communication issue
> >  - Notifying releasing on LKML frequently.
> >  - Preparing more documents for kernel developers.
> >  - Feeding back kernel developers' opinions.
> > 
> > - Solving debuginfo issue
> >  - in the short term, notifying how to minimize debuginfo size.
> >  - in the mid term, making dummy (function-entry) debuginfo.
> >  - in the long term, Roland's dwarf compressor can solve this issue.
> > 
> > - Upstream first issue
> >  - Utrace/Uprobe
> >   - Develop code on LKML and embrace feedbacks.
> >   - Involving main kernel maintainer to speed up the code merging.
> >  - Systemtap itself
> >   - Merging a part of runtime and basic tapset to kernel tree, which
> >    will provide us a permanent API for systemtap generated code.
> >   (BTW, I'd like to suggest modifying ftrace plug-able and systemtap
> >    generating ftrace-plugin tracers. This will be more acceptable for
> >    upstream because we don't need to add so many code).
> > 
> > Any other issues and ideas?
> 
> That's a pretty good list.  Other things to think about
> 
> *) One of the really important reasons why SystemTap needs to move
>    runtime into the kernel is because especially for the community
>    distributions, Fedora for example releases regular bleeding-edge
>    kernels so that end users can help provide badly-needed testing of
>    development kernel.  So if Systemtap needs to be updated from git
>    to deal with changes in the development kernel, Fedora users who
>    are using the bleeding edge kernels won't be able to use Systemtap
>    unless it is released very often as Fedora, Open Suse, and
>    otherwise packaged for other community distributions.  If the
>    SystemTap runtime is bundled with the kernel, then it's much more
>    likely that end users who want to use the daily kernel RPM's will
>    also be able to use SystemTap.
> 
> *) Systemtap needs to be adpted to use tracepoints, quickly; the
>    kernel markers for the scheduler have disappeared and replaced with
>    tracepoints.  I've getting pressure to replace ext4's markers with
>    tracepoints, and eventually I suspect markers infrastructure will
>    probably disappear entirely since tracepoints are perceived as
>    better and as their replacement.  Personally, I haven't had a
>    chance to analyze them deeply enough to know whether this is true,
>    but it's clearly the long-term direction.  (And yes, this is part
>    of efforts to provide a tracing solution that assumes SystemTap is
>    not part of the picture.)
> 
> The idea of using the ftrace infrastructure is a good one; since
> SystemTap resisted making an effort get its runtime into the kernel,
> now that the ftrace infrastructure is in the kernel, the principle of
> not merging code that duplicates functionality means that this makes
> Systemtap now needs to adapt what infrastructure did get merged for
> its purposes, since it will be much more difficult get parallel
> functionality merged into the kernel.
> 
> Regards,
> 
> 						- Ted

hi,

We have been actively looking at and adding tracepoints to the lttng
kernel tree via the ltt-dev list to support Systemtap. These tracepoints are
being added at "key" kernel points in the fs, vm, scheduler, and other
subsystems. Unfortunately, we just realized that these tracepoints are not
going to be proposed for a merge until lttng is proposed for merge. Systemtap
can not be held up by this.

Therefore, I was thinking of proposing 100+ tracepoints that are
currently in the lttng tree (and not upstream, but many have already
been reviewed upstream), on lkml. If we also propose Systemtap specific set of 
markers to interface, with these tracepoints, then Systemtap will work out of
the box with no debuginfo, no gcc changes, and be effective immediately to 
filter ext4 debug information.

Longer term, we can look at merging markers into tracepoints, having
Systemtap directly interface with tracepoints, and merging
utrace/probes. This proposal makes Systemtap immediately more useful on 
upstream kernels, while longer term issues are addressed. thoughts?

thanks,

-Jason