Re: tapset feedback

[Roland McGrath <roland at redhat dot com>]

> One thing I would recommend is a conceptual split between "tapsets",
> which export probe points and a system library, which would export
> general-purpose safe functions.

Why is this advantageous?  The problems you've cited argue for some kind of
name spaces or module system for systemtap functions and probes.  But I
don't off hand see how they lead you to conclude that distinguishing these
two kinds of libraries (function libraries, and probe libraries, which some
people like to call tapsets).  

> 2. I am not running 2.6.14, 2.6.9-20.ELsmp, or 2.6.9-24.ELsmp on any of
> my machines, so I cannot use the syscalls tapset. I mention this not to
> pick on that tapset, but to point out that we have a serious maintenance
> problem created by the way we have implemented tapsets. 

Hopefully most of these kinds of troubles point to areas where we need to
consider alternative implementation strategies that would be less kludgey
and version-dependent in this way.  

> A. What if one of the functions matched does not exist in the current
> kernel?  Right now the compilation fails.

What does that mean?  A wildcard match will produce some set of actual
probe points, and all of those will exist in the kernel that matches the
debuginfo examined.  Do you mean the situation when one of the patterns
matches no functions at all?

The differences in semantics you suggest for "func" are sensible things to
want.  I certainly don't think that one thing called "function" and one
thing called "func" with slightly different semantics in these couple of
ways is the right way to express it in any language I'd want to write in.
Maybe someone can think of a better approach to satisfy these needs.


Thanks,
Roland