This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: adding statements in alias definition as epilogue
- From: Guang Lei Li <liguangl at cn dot ibm dot com>
- To: systemtap at sources dot redhat dot com
- Cc: fche at redhat dot com
- Date: Wed, 5 Apr 2006 10:46:52 +0800
- Subject: Re: adding statements in alias definition as epilogue
> OK, how about forking it into independent twins?
>
> probe addevent.tskdispatch.cpuidle = kernel.inline("idle_balance") {
> log_cpuidle_tracedata(HOOKID_TASK_CPUIDLE, 0)
> }
> probe addevent.tskdispatch.cpuidle.backtrace =
kernel.inline("idle_balance") {
> log_cpuidle_tracedata(HOOKID_TASK_CPUIDLE, 1)
> }
>
I ever thought abut doing like this. But the biggest problem of it is not
only the redundant codes, but it will have trouble if you use wildcard(*)
to specify a group of hooks, for example:
probe addevent.tskdispatching.* {}
will cause both addevent.tskdispatch.cpuidle.backtrace &
addevent.tskdispatch.cpuidle to be triggered.
> This assumes that per-probe backtrace configuration makes more sense
> than, say, a single global variable.
'backtrace' used inside the probe definitions is a local variable, which
is cheaper than using a global variable. And it also enables to turn
on/off backtrace for each event separately instead of turn on/off all
backtraces as a whole.
>
> It still seems like a big step to introduce this inverted data/control
> flow. We would have to consider composing multiple levels of aliases,
> to make sure a programmer and a user can reason easily about what
> should happen.
>
> - FChE
Yes. Maybe some syntax for specifying different kinds of aliases need to
be introduced.
Besides my specific need of alias definition as epilogue, I think it is
also useful if you want a filter:
probe derived_probe := alias_with_filter_codes {
filter_on = 1
scsi_lun = 2
scsi_dev_major = 3
}
- Li Guanglei