This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Discussion at Linux Foundation Japan Symposium
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Theodore Tso <tytso at mit dot edu>
- Cc: systemtap at sources dot redhat dot com
- Date: Sun, 11 Jan 2009 11:29:12 -0500
- Subject: Re: Discussion at Linux Foundation Japan Symposium
- References: <20081221003831.GG24081@redhat.com> <20081222181921.GH23723@mit.edu> <20081222203747.GA4195@redhat.com> <20081223211306.67D29FC3B7@magilla.sf.frob.com> <20081223223217.GW23723@mit.edu> <49518856.80907@redhat.com> <20090110024810.GL23869@mit.edu>
Hi -
On Fri, Jan 09, 2009 at 09:48:10PM -0500, Theodore Tso wrote:
> [...]
> *) One of the really important reasons why SystemTap needs to move
> runtime into the kernel is because especially for the community
> distributions, [e.g. rawhide].
> 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.
That is one possible solution for this specific problem -- rawhide
systemtap users who're unable/unwilling to build systemtap out of git
occasoinally. (Remember that the recent 2.6.28 breakage took a few
hours to fix.)
Another solution would be for rawhide-style distributions to
aggressively package systemtap snapshots into their development
streams -- as some are doing already. (We could have semiautomated
snapshots going straight into fedora rawhide too, and could increase
the rate of minor releases.)
> *) Systemtap needs to be adpted to use tracepoints, quickly [...]
We will work on this very soon.
> and eventually I suspect markers infrastructure will probably
> disappear entirely since tracepoints are perceived as better and
> as their replacement.
(That would probably hurt lttng more than it would systemtap.)
> 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. [...]
I hope that before this long-term direction is brought into effect,
someone does sit down and analyze the issue deeply enough.
> 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.
You overestimate the amount of duplicated functionality. For modern
kernels, systemtap uses the standard in-kernel relay API, with a tiny
shim. (If the relay API were ever removed, systemtap would just
switch to another existing API. Plain buffering is not rocket
science.)
- FChE