This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/3887] Need a syntax to specify probes alternatives


------- Additional Comments From joshua dot i dot stone at intel dot com  2007-01-18 22:15 -------
(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...

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=3887

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]