[lttng-dev] How to disable an event that's been enabled by a wildcard selection or -a?

[Woegerer, Paul]

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:mathieu.desnoyers at efficios.com] 
> Sent: 7. toukokuuta 2013 17:16
> To: Woegerer, Paul
> Cc: lttng-dev at lists.lttng.org
> Subject: Re: [lttng-dev] How to disable an event that's been enabled by a wildcard selection or -a?
>
> * Woegerer, Paul (Paul_Woegerer at mentor.com) 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
> lttng-dev at lists.lttng.org
> 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