On 08/16/2013 02:08 PM, Ikaheimonen, JP wrote: > 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'.
If that is the intention, then it would be better to specify the commands in reverse order: # lttng enable-event "!ab" -u # lttng enable-event "a*" -u or even better: # lttng enable-event "!ab" "a*" -u > 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 ? That is exactly what would happen in an *active* *session* if you issue the commands in the order you originally suggested. Incoming events matching "a*" are recorded up to the point where 'lttng enable-event "!ab"' is executed. From then on, 'ab'-events are excluded from recording. -- Paul > > 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 -- Paul Woegerer, SW Development Engineer Sourcery Analyzer <http://go.mentor.com/sourceryanalyzer> Mentor Graphics, Embedded Software Division _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
