Re: What is a tapset?

[Jim Keniston <jkenisto at us dot ibm dot com>]

n Tue, 2005-07-12 at 09:20, Frank Ch. Eigler wrote:
Hi -
> 
> 
> On Fri, Jul 08, 2005 at 12:35:39PM -0700, Jim Keniston wrote:
> > [...]
> > The HPF procures whatever needed values can't be obtained directly
by
> > translator-emitted code.  For example, for a probed function such as
> > sys_read(), the HPF might pass back the filename associated with the
fd
> > arg (i.e., $fd).  But the HPF relies on the translator to generate
the
> > appropriate code to procure and pass in the value of $fd.
> 
> There is an interesting (type) safety issue in passing target
> variables (or indeed, a script-side variable) to a C function.  At
> some point, the translator will want to treat them all as numbers or
> strings.
> 
I agree.

> One might imagine casting pointers to numbers, but of course
> casting them back to pointers within the C code is dangerous.  That
> code may have no practical way of verifying the validity of these
> incoming "pointers" at all.
> 
Yes, the callee has to trust the caller to pass valid args, and the
caller has to trust the callee to do the right thing with them. 
That's C.  The danger is low in the typical case, where the caller
and callee are both written by the same person.

> > [...]
> > - I've never been comfortable with the requirement that you can
specify
> > a handler prologue only if you also specify an alias.  Seems like we
> > could get past this by using a different keyword (e.g., "export"
instead
> > of "probe") when you're specifying a handler prologue instead of a
> > handler.
> 
> I thought joining the two concepts made some sense.  If prologues were
> a separately declared widget without a distinct name, then the user
> would not have a marker in the script source that tells apart the case
> where a prologue is being pulled in vs. one where one's not.
> 
Since we're trying to be "safe," I assume the author/user of an
end-user script will be able to specify which tapset (set of predefined
probepoints+prologues) his script refers to.  He'll get the prologue
associated with the probepoint specified in his script.  If he pulls
in multiple tapsets that have prologues for the same probepoint,
then SystemTap can warn about the ambiguity.  That would be a case
where an alias would be handy to resolve the ambiguity.

My concern is that the standard probe definition (e.g.,
kernel.function("foo")) may be a perfectly satisfactory handle for
the probepoint, and we shouldn't HAVE to invent an alias for it just
because we also want to provide a prologue.

> 
> > One last thing... Frank and Vara seem to agree that a tapset does
> > NOT include any predefined handlers (e.g., "canned" tracing code).
> > Is there a general consensus on this?
> 
> Is there a design for "predefined handlers", i.e., rough syntax for
> declaration and use, and an outline of its behavior?
> 
Not one that anyone has bought into, but we're creative.  I suggested
the ability to name handlers some time ago.  Given the alias and
prologue

probe kernel.syscall("read") = kernel.function("sys_read") {
	fd = $fd; buf = $buf; count = $count
}

you could define a handler named "trace" -- e.g.,

handler trace kernel.syscall("read")
{
	print("read (%d, %p, %u)\n", fd, buf, count);
}

Then a user could refer to that handler as (say)
kernel.syscall("read"):trace instead of having to write his own handler
to trace that function.  You might refer to all handlers named "trace"
for all system-call entry points as kernel.syscall(*).entry:trace. 
This syntax could be used in the command line ("Enable the following
predefined handlers") on in an .stp file -- e.g.,

include kernel.syscall("read"):trace
// "include" could be "use" or "import" or whatever you like.

On a related note, Frank suggested elsewhere moving the alias clause
to a separate statement.  This would be OK, but then you couldn't
use the "probe" keyword to define both prologues and handlers --
you couldn't distinguish them syntactically.  I'd suggest the above
syntax, where we use the "handler" keyword to define handlers and
the "probe" keyword to define aliases and/or prologues.  (We could
also support an "alias" statement, which would define an alias for
a previously defined probepoint, but I also like the current ability
to define the alias along with the prologue.)

> 
> - FChE
> 

Jim