Re: Discussion at Linux Foundation Japan Symposium

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

> > >    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.
> 
> What do you believe is wrong with tracepoints?  [...]

I would not say "wrong", just that they represent a different set of
trade-offs.  Markers are easy to attach to by code that is not
hand-coded for each event type.  Tracepoints (and ftrace engines) are
on the other extreme: they need hand- or hard-coded code for each
individual event.  This implies that generic markers can be used from
systemtap without debuginfo, whereas generic tracepoints need
debuginfo or else future tech in the form of C code parsing.

There are also some other minor issues, such as dormant markers being
lighter weight than dormant tracepoints.


> [...] but aside from needing to write custome probe modules for the
> 0.01% edge case when I need to filter on something other than a
> single device or inode number to reduce the amount of data going to
> userspace before I do userspace-side filtering, it looks like it's
> pretty close.

If that's all you need to do, and you're up for writing all the
kernel- and user-side machinery by hand, that's great.  Many users are
not of that calibre.


> > 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.)
> 
> Well, if it's not a lot of code, great!  Then it shouldn't be that
> hard to prepare the code for upstream submission [...]

Perhaps.  I was talking about not a lot of *duplicated functionality*
code.  There is a bunch of code that is highly systemtap-specialized
and approximately useless to "in-tree" users.  I'll review and resend
an older analysis so you can see the specifics of this issue.


> What is there does seem to be problematic enough that people need to
> track bleeding-edge Systemtap if they want to use bleeding-edge
> kernels, which in the long term is a lot of work for all
> concerned....

True, it is *some* work, and it is *ongoing* work.

There is another side to it though.  The systemtap runtime is not
done: it is changing regularly.  If instead of being shipped with
stap, there were a variety of versions of it frozen into given
kernels, we would have to fork the userspace side of systemtap all the
time.  While some may have the luxury of caring solely about the
bleeding edge, we have a broader clientele.

- FChE