Re: adding statements in alias definition as epilogue

[Guang Lei Li <liguangl at cn dot ibm dot com>]

systemtap-owner@sourceware.org wrote on 2006-04-05 20:03:23:

> Guang Lei Li <liguangl@cn.ibm.com> writes:
> 
> > [...]
> > probe addevent.tskdispatching.* {}
> >
> > will cause both addevent.tskdispatch.cpuidle.backtrace & 
> > addevent.tskdispatch.cpuidle to be triggered.
> 
> Actually, it doesn't: the wildcard only consumes one component of the
> probe point name.
I tried, and found:
probe addevent.tskdispatching.* = probe addevent.tskdispatching.cpuidle
but addevent.tskdispatching.cpuidle.backtrace is removed away from the 
generated probes.

> 
> > And it also enables to turn on/off backtrace for each event
> > separately instead of turn on/off all backtraces as a whole.
> 
> I see that, but is this capability important & useful?  Plus, apropos
> an earlier message, how does the concept of high-performance binary
> tracing mesh at all with slow and bulky backtrace generation?
> 
Because current backtrace printing is costly, so I want to let the user to 
only turn on backtrace for those events necessary.
But you are right, backtrace printing is too slow, we need a faster way of 
getting the backtrace

> 
> > [...]  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
> > }
> 
> This style of usage could be accommodated with explicit code
> (analogous to "if (target() != pid()) next") instead of alias epilogues.
It is only suitable for filtering by pid, which provides a way of passing 
in the target pid by "stap -c cmd" or "stap -x targetid". But how can you 
pass in filter_on, scsi_lun & scsi_dev_major? The newly arguments support 
in stap could make it, but it seems not a good solution in this example.

> 
> 
> - FChE