Re: Discussion at Linux Foundation Japan Symposium

[Theodore Tso <tytso at mit dot edu>]

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