Miscellaneous questions & comments

[Mike Mason <mmlnx at us dot ibm dot com>]

I've been jotting down questions as I've been collecting info for the Tapset Writer's Guide.  It's about time I ask some of them :-)

- Should the "name" variable be defined in every probe?  It's used inconsistently in the current tapsets.  Some define it as the probe alias name, some as the probed function name, some don't define it at all. Given that we can use pp() and probefunc() to get the probed function info, seems like probe alias name makes the most sense.  If that's what we want, can we define a function similar to pp() and probefunc() that returns the alias name?  Might be difficult given that aliases can specify other aliases.

- Should the "argstr" variable be defined in every probe?  Again, that's not done consistently in the existing tapsets.

- How should we handle tapset probes that don't resolve on all supported architectures?  For example, scheduler.ctxswitch probes __switch_to(), which is marked with __kprobes on x86_64, but not on other architectures.  Trying to use that probe alias on x86_64 results in a "no match for probe point" error.  Seems like something more informative, such as "this probe not supported on x86_64" would be better.  It there some way to mark the probe such that it emits that type of error?

- Is there any way to do tapset versioning?  I can envision situations where a script may want or need to do something different depending on the version of the tapset.

- It would be nice to be able to pass back more than one value in a function.  For example, the tokenize() function I recently wrote should ideally pass back a token and a pointer to the beginning of the next token.  Since systemtap doesn't have a "pass by reference" capability, I can't pass back the next token pointer.  I have to keep that pointer as a global, making the function non-reentrant.  Any chance we could add "pass by reference" in the future?

- This may be too "blue sky", but it would also be nice to have structures.  I've run into several situations where an array of structures would have made things easier, rather than one array for each element in the structure.

That's all for now.

Mike Mason