Re: What is a tapset?

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

Hi -


varap wrote:
> [...]
> >(BTW, [kprobes] is the primary mechanism, but is unlikely to remain
> >the sole mechanism even for synchronous probes.)

> Any ideas/insights into what the other mechanisms might be for 
> synchronous probes.

I expect systemtap to eventually support statically inserted
instrumentation of its own kind, and any hooks already available in
the kernel.


> [...]
> I would like to mention this notion of tapset code is not only for "C" 
> based tapsets but also valid for script based tapsets.

Maybe, but a parallel mechanism for implementing your style of
automagic variables in within the script language only has not been
specified.


> >If this is a fair characterization, then I believe that this is a bit
> >over-complicated and under-powered for what we need.  
>
> Can you explain what is the complication 

Jim already did.  The business of registration (crossing user/kernel
boundaries), declarative requests for target-side variables, copying
values in/out via void* buffers.

> and what powers that we need to define tapsets this method doesn't
> give?

Being an implicit mechanism (not directly visible from the end-user
script), it's hard to invoke deliberately.  It may or may not compose
well with others.  As I mentioned before, there is particular
fragility in your scheme's passing of target-space variables to the C
functions, in that probe points must match between the C and script.


> [...]
> I am also assuming if there happens to be more than one target_var 
> defined in the probed function translator is smart enough to find the 
> active one and pass it to c_function.

The syntax and behavior of target value accesses has not been built
yet, but of course the translator should perform tie-breaking or print
warnings/errors.  

But all this is independent of how those values are used - that is
whether or not they are passed to some C function.  Some ordinary
script code will want to extract values this way, so the "C tapset"
angle is not relevant.


> [...]  This still doesn't address one of the questions you have
> raised earlier which is "what is the guarantee that $target_var is
> still valid with the changing versions of the kernel?"

I don't recall raising this as a question.  The translator will have
to search for $target_var for every compilation run.  If the variable
exists for the selected kernel at the context of the given probe
point, then it will work.

I still don't see why this comes up as a distinguishing factor.  Even
in your scheme, you wanted the translator to be able to pass to your C
functions selected target-side variables.  So the code for finding
those variables is the same.
 

> Questions:
> If c_function wants to export more than one variable, how does it do, 
> who allocates memory for those return values

Jim also raised this.  Depending on actual needs of instrumentation
authors/users, it may be sufficient to support only a very limited
variety of signatures and copying/allocation conventions.  For
example, it might be possible to let these functions write to
systemtap globals through the runtime API.


> Let us c_function is expecting target_var to be of type int but due to 
> kernel changes target_var now become char how does translator know that 
> raises error instead of passing wrong type, in my proposal type 
> information was part of the registration hence we could verify.

But the "we" who does the verification in the latter case is the same
translator that figures out the type of the target variable!  If some
type combination becomes invalid, then the translator's type-checking
logic will start signalling errors in either case.


> In the above the only difference between probe point definition and
> usage or reference is one has alias and other doesn't. I am not very
> happy with using aliases to differentiate between the two [...]

If others are also unhappy with overloading the "probe" keyword to define
both probes proper as well as aliases, then we can pick a new keyword for
the latter.  Like "alias foo.bar = baz { ... }".


> [...]  Based on your above response you seem to agree to the basic
> concept that tapset (both "C" and script) is a probe point and
> tapset function pair, please let me know if this is not true.

I don't know what this means.  Rather than defining the grand term
"tapset", we can just focus on particular extension mechanisms.  There
are already two or three already implemented or planned:

- automatic inclusion of scripts from a library, to satisfy undefined
  references in end-user scripts
- probe aliases
- access to target values

I believe lot can be accomplished by these alone.  But there is wide
suspicion that we will also need:

- ability to explicitly call into a C function

You are proposing another alternative or additive:

- ability to implicitly call into a C function, to satisfy references
  to variables scripts 

I don't see much point defining a "tapset" artifact as code that
necessarily uses all/any of (say) mechanisms #1, #3, and #5.  Let's
instead simply treat the extension mechanisms individually, and
consider issues with their natural composition.


- FChE