Messages in this thread | | | Subject | Re: [RFC PATCH 0/4] perf: Custom contexts | From | Peter Zijlstra <> | Date | Wed, 16 Mar 2011 19:02:37 +0100 |
| |
On Wed, 2011-03-16 at 14:53 -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Mar 17, 2011 at 12:47:01AM +0900, Masami Hiramatsu escreveu: > > (2011/03/16 10:03), Frederic Weisbecker wrote: > > > Doh you're right. && would have two meaning. > > > No we should probably keep a && b has a meaning of we are > > > in the range a AND in the range b. Both at the same time, with > > > a evaluated first and then b. We also need to ensure than > > > a && b doesn't mean the same than b && a. You're right, perhaps > > > we need another operator to expression inclusion, or we need to > > > assume that specific meaning of &&. > > > > > > For what I wanted to express in the example above, || seem be the > > > right choice: -e inst*@(..lock:*acquire(B) || lock:*release(B)..) > > > > > > So || would mean union and && would mean inclusion. > > > > Hmm, would we really need that kind of complex rules? > > It seems that we only need union case. If so, I'd suggest > > you to use ',' to express that, instead of ||. > > > > -e inst*@(..lock:*acquire(B),lock:*release(B)..) > > Yeah, I somehow was avoiding the comma operator because it could be used > to represent multiple events, but then its a different context, using it > to represent a circular list of ranges in the @ (at, location) expression > seems ok. > > 1. '..lock:*acquire(B)' is armed, 'lock:*release(B)..' isn't > 2. '..lock:*acquire(B)' trigers, which causes 'lock:*release(B)..' to be > armed > 3. 'lock:*release(B)..' triggers, which causes '..lock:*acquire(B)' to > be armed, rinse, repeat
How about we start writing proper EBNF syntax rules for this stuff, its getting seriously out of hand.
| |