This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Discussion at Linux Foundation Japan Symposium


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]