This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Miscellaneous questions & comments


Mike Mason wrote:

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.


My suggestion would be unless there is a good reason let us make it consistent and agree upon one implementation. It is important for the script writer to know what they get at each probe point and if there is a common information at each probe point it is good to have consistency. Any disagreements on this?


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

Same here.



- 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?


This brings up couple of thoughts.
1) If it is not o.k to probe __switch_to on x86_64 is it really o.k to probe this function on other platforms. In other words shouldn't we be marking these kinds of functions that available across all the platforms with __kprobes on all the platforms?
2) Translator will eventually come across errors in probing the functions marked with __kprobes anyway so is it a good idea to automatically add the functions marked with __kprobes to the translator blacklist in every installation. If yes, i guess trick is to figure out what time during the life of systemtap we should do this automatic update so as to not to be out of sync with the debug info package updates.



- 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.


Can you give some examples? This may be an issue during these periods where tapsets are still evolving but as an end user i don't want to deal with the complexities of tapset versions. I want to write a script and i expect it to work across all the platforms (assuming i am not probing platform specific code) using any supported version of systemtap. I understand this may not be possible at this time due to rapid evolution our project is going through but as far as i know we are trying to provide backward compatibility to prevent such failures.


- 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?

I personally think we shouldn't introduce complexities such as pass by reference in a scripting language, we will be loosing the simplicity of the language we have now. Isn't that the case with most scripting languages like awk, PERL, Shell etc.



- 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.

I always thought we should support structures to make it easy and if i understood correctly Frank is not opposed to this idea in principal but wanted more evidence of such a need before he takes on the complex task of structure support. Can you give few examples of where you feel you need structure support and how difficult it is to do the same thing now. I think that will help in shedding more light into this problem.



That's all for now.


Mike Mason






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]