This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Few queries on tapset interface
On Wed, 2005-06-01 at 13:22, Frank Ch. Eigler wrote:
...
> This would be closer to current syntax:
>
> global entry_time, my_count, my_fd, read_times
>
> probe kernel.syscall("read") {
> thread->entry_time = $timestamp; # "macro" variable
Sample code - yay! I have some suggestions...
If we're going to use $var to mean "var in the context of the probed
function," then I think it's confusing to start names of
language-defined values (such as $timestamp) with '$' as well. We also
run the risk of name collisions. Perhaps use @ (or $_) for the former
and $ for the latter.
I think that the thread->assoc_array syntax is confusing, especially now
that the language supports the C-language meaning of ->. I think
entry_time[$thread] would be clearer than thread->entry_time (assuming
$thread gets you a thread- or task-specific number).
> thread->my_count = $count; # function argument
> thread->my_fd = $fd; # function argument
> trace ("my_count = " . string(thread->my_count) .
> "my_fd = " . string(thread->my_fd))
> }
>
> probe kernel.syscall("read").return {
> if (thread->entry_time) {
> read_times[$syscall_name] # variable from provider alias
If it's from the provider alias, wouldn't it be just syscall_name, not
$syscall_name?
> += $timestamp - thread->entry_time
> }
> trace ("syscall " . $syscall_name .
> " return value = " .
> hexstring ($retvalue)); # function pseudo-argument
> }
The runtime provides _stp_printf() for printk-like logging, so you could
do something like
_stp_printf("syscall %s return value = %#x\n",
$syscall_name, $retvalue);
although you might not call _stp_printf by its real name, in case we
need to preserve the abstraction.
>
> probe end {
> for ([syscall] in read_times) {
Why "[syscall]" rather than "syscall" in the "for" clause?
> trace ("syscall " . syscall .
> " total-time=" . string (read_times[syscall]))
> }
> }
>
...
>
> - FChE
>
Jim