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: request to add additional runtime path


"Guanglei Li" <guanglei@cn.ibm.com> writes:

> [...] The places it looks at are those such as scsi layers, 
> io schedulers, syscalls etc.

Nice.


> /* when a request is retrieved from request queue */
> probe addevent.ioscheduler.elv_next_request
>         =  kernel.function("elv_next_request")
> [...]
>                 log_tracedata_common(5)
>                 log_ioscheduler_tracedata_extra_elv_next($q)
> [...]
> Here you can see log_tracedata_common(5), 5 is the hookID. I think 
> it's better to use IOSCHED_NEXT_REQ_HOOKID instead of 5. So that it's 
> easier for maintenance.

But in this case, the literal 5 appears in script.  You could define
script globals in a separate .stp file thusly:

  # tracedata_hookids.stp
  global IOSCHED_NEXT_REQ_HOOKID # , FOO_HOOKID, BAR_HOOKID

  probe begin {
    IOSCHED_NEXT_REQ_HOOKID = 5 
    # ...
  }

Then your original stp file could refer to the variable name directly.
No C-level shared headers are needed.  The translator will pull in the
tracedata_hookids.stp file automatically.


> function log_ioscheduler_tracedata_extra_elv_next(var:long)
> %{
> [...]
>                 rq = list_entry_rq(q->queue_head.next);
>                 _stp_printf("%s|%ld|%ld", q->elevator.elevator_name, 
> rq->rq_disk->major, rq->rq_disk->first_minor);
>         }
> %}

Instead of using stp_printf, and thus calling directly into the
runtime, you might consider instead making this a function that
returns a string, which the caller script routine could print.  That
string could be built with sprintf or a friend.


> function filter_by_pid:long()
> %{
> [...]
>         if(cur->tgid != _stp_pid) /* skip stapd itself */
> [...]
>                 if( _stp_target != 0 && cur->tgid != _stp_target)
> [...]

Consider instead a single new contextinfo.stp embedded-C function to
return "_stp_pid", and code the rest of this in script.


> /* Log the data common to all events */
> function log_tracedata_common(hookID:long)
> %{
>         struct timeval tv;
>         struct task_struct *cur = current;
>         /* second|usec|pid|ppid|tid|cpuid|hoodID */
>         do_gettimeofday (&tv);
>         _stp_printf("\n%ld|%ld|%ld|%ld|%ld|%u|%ld|", tv.tv_sec, 
> tv.tv_usec, cur->tgid, \
>                 cur->parent->pid, cur->pid, 
> cur->thread_info->cpu,THIS->hookID);
> %}

This can already be coded as a single script printf statement.


> > It is undesirable for embedded C code to make direct calls to the
> > runtime.  Among other reasons, this is since that API exists for the
> > convenience of the translator, and thus may change frequently
>
> Currently I have no need to put .c files into runtime dir. [...]

I didn't mean putting new .c files there.  I meant *making calls*
directly into the runtime.  While _stp_printf is relatively tame,
there are many functions there that are not.


- FChE


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