adding statements in alias definition as epilogue
Guang Lei Li
liguangl@cn.ibm.com
Wed Apr 5 02:46:00 GMT 2006
> 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
More information about the Systemtap
mailing list