Re: C tapsets take 2

[fche at redhat dot com (Frank Ch. Eigler)]

prasadav wrote:

> [...]  During the module initialization tapsets registers the
> functions in the module and as well as the data exported by the
> functions with systap module. [...]

So you imagine these functions calling into some new kernel-resident
module to register their own availability?  And you imagine the
translator calling into this kernel module to query what functions are
available, and what target-side symbolic data they might like to have?
If so, that would be a major departure from the current operational
model, since we currently run entirely as a user-space tool, up to the
point of loading and running the compiled probes.  The user-space
translation permits cross-compilation for example.


> [...]
> Following example illustrates the "C" language API.
> 
> Let us say a kernel expert would like to provide a tapset function for
> sys_read systemcall when the file position is updated and exports the
> new fileoffset and filename. That function would be registered as
> follows
> 
> tapsetfunc_register("kernel.function(sys_read).linenum(9)", //location
> in the probed function
>              tapf_sysread_done,  //tapset function that can be called
> in the probe handler
>              NULL, //args of the probed function need in the tapset function
>             "pos, file", //local variables of the probed function
>             "long long, char *" //data type for return variables
> );

I wonder how this can work if a user probe script uses a probe point
that is anything other than an exact match for this declaration
("... linenum(9)").  In particular, that source location provides a
reference point against which symbolic access to local variables (and
indeed, function parameters) needs to be made.  If the probe was
actually placed at any other spot (say, linenum(8), or .return, or
upon entry), then the reference points do not match, and target-side
variables cannot be extracted for both contexts.


> [...]
> /* same signature as madvise_dontneed */
> static void inst_madvise_dontneed(struct vm_area_struct * vma,
>         unsigned long start, unsigned long end)
> {
> [...]
> }
> 
> As you can see in the above example the instrumentation function does
> lot more work including walking through the list, locking etc
> which i feel is lot easier for kernel expert to write than systemtap
> to automatically generate the code.

In this case, there does not appear to be a probe point associated
with this function.  One could consider it an "ordinary" auxiliary
function, which happens to be written in C.  Interfacing to such an
animal is different again, because for example there is no
source-level probe point context.


Maybe you could work out an example involving the entire flow of your
proposed solution, importantly including a chronological sequence.
(When do the various steps happen, which piece of code does each, who
writes which piece of code, where each piece lives.. ?)


- FChE