This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Miscellaneous questions & comments
- From: Vara Prasad <prasadav at us dot ibm dot com>
- To: Mike Mason <mmlnx at us dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Mon, 04 Dec 2006 16:07:36 -0800
- Subject: Re: Miscellaneous questions & comments
- References: <457481B7.1050409@us.ibm.com>
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