tapset feedback

[Roland McGrath]

> All I'm proposing is that we have a well-defined and documented set of
> library functions.  

For general-purpose library functions, I agree.

> And regardless of how it is implemented, I don't think we should call it
> a tapset because it doesn't act like a tapset.

I have never found the term "tapset" especially useful at all, but some
people seem to like it.  To me, it means nothing other than a library
intended to be useful for a particular topic.  It makes sense to me that a
topical library might well provide both probes and functions that user
scripts can use to interrogate the system about that topic.  I certainly
agree that what a library exports to users (probes and/or functions) should
be well-defined and documented, and clearly distinguished from any named
entities used for internal implementation purposes within the library.

> I'm thinking about tapsets here. For example, "kernel.syscall.*" may
> contain functions that the current kernel doesn't implement.

Here I think we should consider first what are the desireable high-level
semantics for referring to exported library-defined probe types such as
these, and then separately the implementation issues in the library code
and in the language to make that happen.

The status quo is not what we want, where kernel.syscall.foobar can
translate into something that won't resolve and kernel.syscall.* just
matches that along with everything else and fails to resolve it later.

I see two reasonable choices for the semantics a user of the language would
want.  Firstly, that probes exported by a library should work, and a
library should not export any probes that cannot work.  So syscalls.stp
would not export kernel.syscall.foobar at all if sys_foobar doesn't exist.
Hence "kernel.syscall.*" won't match foobar and won't ever consider it so
as to have a problem.  If a user script might want to use
kernel.syscall.foobar directly, then it will have to use % conditionals to
avoid those uses on kernels where the probe won't be defined because it
can't work; i.e., have to know the kernel versions to test for, or perhaps
allow libraries/tapsets to export symbolic conditionals so a user can test
with %(have_foobar) in conditionals.  

The other choice is to define a special notion of "never" probes.  Here the
complete set of probe names is a fixed part of the particular tapset's API
to user scripts, across all kernel versions.  So there is always a
kernel.syscall.foobar known to the translator when referenced from a user
script, distinguished from kernel.syscall.somerandomname that doesn't exist
at all.  But depending on the kernel version (or other vagaries of the
individual tapset implementation), kernel.syscall.foobar might actually
boil down to a function entry probe, or it might be defined as a "never"
probe.  A "never" probe never fires, and so no code is emitted associated
with it.  But never probes can have particular effects at translation time,
such as giving you a warning message or an error.  With some combination of
language constructs in scripts and/or in tapsets, and/or translator flags,
you can say things like: warn/err when a never probe is used by name, when
a never probe is one of multiple matches for a probe wildcard, when never
probes are the only matches for a probe wildcard, etc.  For example, it
might make sense to let the syscalls tapset define that
kernel.syscall.wildcard matches should silently ignore never probes, since
if one wants all the syscalls one doesn't care what syscalls known to man
don't exist on this system.  But another tapset might have purely topical
names such that some wildcards should cause complaints about unavailable
probe types.  Likewise, some scripts will be written not to care about the
omitted probes (and should be able to easily say to suppress warning about
such), while some will use more precise interactions between probes and
want errors if any probe is not going to be installed; still others might
want to programatically know in one probe when another probe is never going
to fire (a la the %(have_foobar) conditionals).


I tend toward the latter choice, though it clearly has many details to be
decided.


In implementing either approach, what we can already use in tapsets is the
version conditionals.  i.e., in the first approach use conditionals to omit
probe definitions entirely; and in the second case, to define probe aliases
as "never" instead of as function probes and such.  If doing "never" probes, 
it seems useful to give tapset-writers some more implicit mechanisms, e.g.:

probe kernel.syscall.foobar = kernel.function("sys_foobar") or never { ... }

(This syntax not to be taken seriously.)  i.e., specify to the translator
that a probe alias uses some low-level probe flavor if that matches
anything, or falls back to being a "never" probe if not.



Thanks,
Roland