Re: adding statements in alias definition as epilogue

[Guang Lei Li <liguangl@cn.ibm.com>]

> 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