Bug 3887

Summary: Need a syntax to specify probes alternatives
Product: systemtap Reporter: Josh Stone <jistone>
Component: translatorAssignee: Frank Ch. Eigler <fche>
Status: RESOLVED FIXED    
Severity: enhancement CC: fche
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:

Description Josh Stone 2007-01-18 19:55:14 UTC 
This enhancement idea is a close cousin to bug #2645.

I would like to have a way to list several alternatives for a probe point, and
have the translator pick exactly one for implementation.  With this, one could
specify a preferred probe point, with an alternate probe point if the first is
not available.

My syntax suggestion is to use the boolean-OR ('||') operator when defining a
probepoint, and the translator will resolve in the typical left-to-right,
short-circuit fashion.  For example, given 'probe kernel.function("foo") ||
kernel.function("bar") {}', the translator will resolve as follows:

 probeable: | probe
  foo | bar | used
  -------------------
   Y  |  Y  | foo
   Y  |  N  | foo
   N  |  Y  | bar
   N  |  N  | *error*

This sort of feature will be useful for defining portable tapsets and scripts. 
Some example usage ideas:

  probe scheduler.context_switch = kernel.mark("context_switch")
        || kernel.function("__switch_to")
        || kernel.inline("context_switch") {}
If markers are available, use that.  Otherwise, try __switch_to, which has good
parameter information.  Finally, try context_switch, but parameters might not
work in inlines.  Note that on some kernels all three might be ok, but only
*one* is used.

  probe scsi.ioentry = kernel.function("scsi_prep_fn")
        || module("scsi_mod").function("scsi_prep_fn") {}
This explicitly declares how to search for the function "scsi_prep_fn".  The
same can almost be achieved using the '?' operator on both alternatives, except
that this new methods *requires* that one resolves correctly.  (Consider the use
of "scsi.*" -- if using '?' the ioentry might silently disappear on failure.)

  probe event.foobar = kernel.function("foobar") || foo_and_bar {}
  probe foo_and_bar = kernel.function("foo"), kernel.function("bar") {}
This demonstrates how to achieve grouping.  The translator will generate a
single probe on "foobar" if it exists, or else it will use two probes on "foo"
and "bar".

We'll have to consider operator precedence and semantics.  For example, what
should happen in the following cases?
  1. probe foobar = foo ? || bar {}
  2. probe foobar = foo || bar ? {}
Comment 1 Frank Ch. Eigler 2007-01-18 20:24:39 UTC 
It is an interesting idea.
One thing to consider though is that the different probe points are unlikely
to be completely interchangeable.  Specifically $target variables available at
each variant may be quite different, requiring different handlers.

So how about associating the handlers with the alternatives?

probe kernel.mark("foo") { $arg1 ; $arg2 } ||
      kernel.function("bar") { $var1 ; $var2 }

or even with less punctuation:

probe kernel.mark(....) { }
else kernel.function(....) { }

Another issue to consider is what to do with aliases.
Comment 2 Josh Stone 2007-01-18 22:15:06 UTC 
(In reply to comment #1)
> One thing to consider though is that the different probe points are unlikely
> to be completely interchangeable.  Specifically $target variables available at
> each variant may be quite different, requiring different handlers.

True, but aliases come to the rescue in that case.

> So how about associating the handlers with the alternatives?
> 
> probe kernel.mark("foo") { $arg1 ; $arg2 } ||
>       kernel.function("bar") { $var1 ; $var2 }

Aliases give you a way to split the necessary parts, and still share a common body:

probe my_foo || my_bar {
    printf("this is important: %d %s\n", var1, var2)
}
probe my_foo = kernel.mark("foo") { var1=$arg1->var1 ; var2=$arg2->var2 }
probe my_bar = kernel.function("bar") { var1=$var1 ; var2=$var2 }

> or even with less punctuation:
> 
> probe kernel.mark(....) { }
> else kernel.function(....) { }

Hmm... you've turned '||' into 'else'?  I suppose if you prefer using keywords
over punctuation, that would be fine.  I'm not sure that 'else' makes sense if
there's more that two alternatives though -- perhaps 'or' as a keyword?

> Another issue to consider is what to do with aliases.

Well, using this for tapset aliases was exactly what I intended, so lets hash it
out.  It seems consistent to just expand aliases as normal.

  probe a = b || c {}
  probe b = w || x {}
  probe c = y, z {}

An instance of alias 'a' would expand to the probepoints 'w' OR 'x' OR ('y' AND
'z').  The comma is effectively 'AND', and the alias levels act as grouping for
operator precedence.  The precedence can get tricky though -- consider:

  probe a, b || c {}

If the comma is just 'AND' then traditionally this would be read '(a AND b) OR
c', but visually the comma seems like a lower precedence, which would make it 'a
AND (b OR c)'.

I'm still uncertain about how the 'optional' flags should behave in this
boolean-like probe resolution...
Comment 3 Frank Ch. Eigler 2007-10-15 19:45:56 UTC 
*** Bug 2067 has been marked as a duplicate of this bug. ***
Comment 4 Frank Ch. Eigler 2007-11-20 04:07:33 UTC 
patch committed
Comment 5 Frank Ch. Eigler 2007-11-20 04:10:33 UTC 
 BTW, the commited syntax is a variant of the optional flag.  I realized that
"||" is really a special case of "? and stop if resolved".  So now we have
probes like:  
probe kernel.function("favorite") !, kernel.function("second_best") !,
kernel.function("worst, but must exist") { }