A question on the suggested feature below: If we do the following set of commands:
lttng enable-event "a*" -u lttng enable-event "!ab" -u The intention is to enable all events starting with the letter 'a' except the event 'ab'. However, if the event 'ab' is already registered in the session, the first command would enable the event 'ab'. Should the second command now disable the event 'ab', or should the command only apply to future registrations of events ? Thanks, JP Ikaheimonen Mentor Graphics -----Original Message----- From: Mathieu Desnoyers [mailto:[email protected]] Sent: 7. toukokuuta 2013 17:16 To: Woegerer, Paul Cc: [email protected] Subject: Re: [lttng-dev] How to disable an event that's been enabled by a wildcard selection or -a? * Woegerer, Paul ([email protected]) wrote: > On 05/02/2013 03:40 PM, Mathieu Desnoyers wrote: > > Hi Paul, > > > > I would be interested to see this feature upstream. Previously was > > not a good timing to pull it in, because we were adding the concept > > of event "enablers" within lttng-ust. > > Sounds great. I will port our patch to master. > > > > > One thing I'm curious about is how you present the logical > > combination with exlusion match are present. For instance, if we > > only have inclusion, we get: > > > > lttng enable-event 'a' > > lttng enable-event 'c' > > lttng enable-event 'zc*' > > > > it turns into : (a || c || zc*) > > > > I expect that negation would look like: > > > > lttng enable-event 'a' > > lttng enable-event '!abc*' > > lttng enable-event 'c' > > lttng enable-event '!cxx' > > Our current solution does not handle '!cxx' correctly. > I will fix that. > > > lttng enable-event 'zc*' > > > > -> !(abc* || cxx) || (a || c || zc*) > > Exactly. The "!something" wildcards are always first and will prevent further > matching with non-! wildcards. > > > > > Am I correct ? If yes, we should expand lttng-tools lttng(1) manpage > > and cmd help with this info. > > I will take care of documentation updates as well. > > > > > Can you make sure it works well with lttng-ust master branch ? > > Once I have a working, tested patch against master I will send it to you. One thing I just remembered: Please make sure that the order of evaluation of filter expressions stays the same, because we plan to add "actions" associated with the filter expressions in the future. Therefore, if we have: lttng enable-event 'a' --filter 'fielname==1' (1) lttng enable-event '!abc*' --filter 'somename>2' (2) lttng enable-event 'c' --filter 'othername==3' (3) lttng enable-event '!cxx' --filter 'thisname="abc"' (4) We want to interpret the filter expressions in this order: (1), then (2), then (3), then (4) within lttng-ust. We also have to assign a clear semantic to those exclusions when a filter is applied. Same for loglevels. This is one of the reasons why I waited to pull your modification: I was implementing the filter, and "enablers", back then. So now there everything is in place, it should become clearer what needs to be done. Thanks, Mathieu > > Thanks, > Paul > > -- > Paul Woegerer | SW Development Engineer > http://go.mentor.com/sourceryanalyzer > > Mentor Embedded(tm) | Prinz Eugen Straße 72/2/4, Vienna, 1040 Austria > Nucleus® | Linux® | Android(tm) | Services | UI | Multi-OS > > Android is a trademark of Google Inc. Use of this trademark is subject to > Google Permissions. > Linux is the registered trademark of Linus Torvalds in the U.S. and other > countries. -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
