All of lore.kernel.org
 help / color / mirror / Atom feed
* How to disable an event that's been enabled by a wildcard selection or -a?
@ 2013-02-08  9:25 Ikaheimonen, JP
  0 siblings, 0 replies; 9+ messages in thread
From: Ikaheimonen, JP @ 2013-02-08  9:25 UTC (permalink / raw)
  To: lttng-dev

Consider the following scenario.
I want to write a script that traces all UST tracepoints of a given application. I have no idea what the names of these tracepoints are. Also, I know that the application uses a library that contains some tracepoints I am not interested about. Now I want to trace all UST tracepoints except the ones I already know about. Is this possible with the lttng commands?

If I enable all tracepoints with "lttng enable-event -u -a" I get all events, even those I do not want. I've tried using "lttng disable-event", and "lttng enable-event" with a filter, but I cannot seem to be able to get rid of the specific events.

Thank you,

JP Ikaheimonen
Mentor Graphics Embedded Systems Division
Nucleus(r) | Linux(r) | 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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to disable an event that's been enabled by a wildcard selection or -a?
       [not found]           ` <009B25148989C6458484484699278506E5385F9C@EU-MBX-01.mgc.mentorg.com>
@ 2013-08-20  9:27             ` Woegerer, Paul
  0 siblings, 0 replies; 9+ messages in thread
From: Woegerer, Paul @ 2013-08-20  9:27 UTC (permalink / raw)
  To: Ikaheimonen, JP; +Cc: lttng-dev, Mathieu Desnoyers

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@efficios.com] 
> Sent: 7. toukokuuta 2013 17:16
> To: Woegerer, Paul
> Cc: lttng-dev@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@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@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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to disable an event that's been enabled by a wildcard selection or -a?
       [not found]         ` <20130507141558.GD5118@Krystal>
@ 2013-08-16 12:08           ` Ikaheimonen, JP
       [not found]           ` <009B25148989C6458484484699278506E5385F9C@EU-MBX-01.mgc.mentorg.com>
  1 sibling, 0 replies; 9+ messages in thread
From: Ikaheimonen, JP @ 2013-08-16 12:08 UTC (permalink / raw)
  To: Mathieu Desnoyers, Woegerer, Paul; +Cc: lttng-dev


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:mathieu.desnoyers@efficios.com] 
Sent: 7. toukokuuta 2013 17:16
To: Woegerer, Paul
Cc: lttng-dev@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@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@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to disable an event that's been enabled by a wildcard selection or -a?
       [not found]       ` <51839435.8010607@mentor.com>
@ 2013-05-07 14:15         ` Mathieu Desnoyers
       [not found]         ` <20130507141558.GD5118@Krystal>
  1 sibling, 0 replies; 9+ messages in thread
From: Mathieu Desnoyers @ 2013-05-07 14:15 UTC (permalink / raw)
  To: Woegerer, Paul; +Cc: lttng-dev

* Woegerer, Paul (Paul_Woegerer@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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to disable an event that's been enabled by a wildcard selection or -a?
       [not found]     ` <20130502134010.GF7035@Krystal>
  2013-05-02 14:00       ` Mathieu Desnoyers
@ 2013-05-03 10:40       ` Woegerer, Paul
       [not found]       ` <51839435.8010607@mentor.com>
  2 siblings, 0 replies; 9+ messages in thread
From: Woegerer, Paul @ 2013-05-03 10:40 UTC (permalink / raw)
  To: Mathieu Desnoyers; +Cc: lttng-dev

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.

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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to disable an event that's been enabled by a wildcard selection or -a?
       [not found]     ` <20130502134010.GF7035@Krystal>
@ 2013-05-02 14:00       ` Mathieu Desnoyers
  2013-05-03 10:40       ` Woegerer, Paul
       [not found]       ` <51839435.8010607@mentor.com>
  2 siblings, 0 replies; 9+ messages in thread
From: Mathieu Desnoyers @ 2013-05-02 14:00 UTC (permalink / raw)
  To: Woegerer, Paul; +Cc: lttng-dev

* Mathieu Desnoyers (mathieu.desnoyers@efficios.com) wrote:
> * Woegerer, Paul (Paul_Woegerer@mentor.com) wrote:
> > Hi David,
> > 
> > On 02/14/2013 05:52 AM, David OShea wrote:
> > > Hi,
> > > 
> > > My understanding (hopefully someone will correct me if I'm wrong) is that each time you invoke 'lttng enable-event', your specification for the events you want enabled is stored and applied, and/or potentially applied later if a new application connects to the session daemon.  All 'lttng disable-event' does is remove one of the specifications you previously provided to 'lttng enable-event', so you can't say 'enable-event *' and then 'disable-event foo:*' to get all events except 'foo:*'.
> > > 
> > > If you could constrain the application to use a particular trace provider name for all of its tracepoints, say "app", then you could just do 'lttng enable-event app:*'.  If you can't do that, then I think you need to fall back on getting a list of all the available tracepoints using 'lttng list -u', parsing this to find all of the available tracepoints, extracting the trace provider name from them, then using 'lttng enable-event <provider>:*' for each provider other than the provider from your uninteresting library.  I think there are APIs that can be used instead of issuing the 'lttng' commands.
> > > 
> > > I would certainly also like a way to be able to, say, enable all events other than foo:* and bar:* using one command.
> > 
> > I submitted a patch that does exactly this a while ago:
> > http://lists.lttng.org/pipermail/lttng-dev/2012-June/018179.html
> > 
> > Although it's not upstream it works well for us.
> 
> 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.
> 
> 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'
> lttng enable-event 'zc*'
> 
> ->  !(abc* || cxx) || (a || c || zc*)

I actually meant:

  !(abc* || cxx) && (a || c || zc*)

Thanks,

Mathieu

> 
> Am I correct ? If yes, we should expand lttng-tools lttng(1) manpage and
> cmd help with this info.
> 
> Can you make sure it works well with lttng-ust master branch ?
> 
> Thanks,
> 
> Mathieu
> 
> > 
> > Thanks,
> > Paul
> > 
> > 
> > > 
> > > Regards,
> > > David
> > > 
> > >> -----Original Message-----
> > >> From: Ikaheimonen, JP [mailto:jp_ikaheimonen@mentor.com]
> > >> Sent: Friday, 8 February 2013 7:56 PM
> > >> To: lttng-dev@lists.lttng.org
> > >> Subject: [lttng-dev] How to disable an event that's been enabled by a
> > >> wildcard selection or -a?
> > >>
> > >> Consider the following scenario.
> > >> I want to write a script that traces all UST tracepoints of a given
> > >> application. I have no idea what the names of these tracepoints are.
> > >> Also, I know that the application uses a library that contains some
> > >> tracepoints I am not interested about. Now I want to trace all UST
> > >> tracepoints except the ones I already know about. Is this possible with
> > >> the lttng commands?
> > >>
> > >> If I enable all tracepoints with "lttng enable-event -u -a" I get all
> > >> events, even those I do not want. I've tried using "lttng disable-
> > >> event", and "lttng enable-event" with a filter, but I cannot seem to be
> > >> able to get rid of the specific events.
> > >>
> > >> Thank you,
> > >>
> > >> JP Ikaheimonen
> > >> Mentor Graphics Embedded Systems Division
> > >> Nucleus(r) | Linux(r) | 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.
> > >>
> > >> _______________________________________________
> > >> lttng-dev mailing list
> > >> lttng-dev@lists.lttng.org
> > >> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> > > 
> > > ----------------------------------------------------------------------
> > > The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.
> > > 
> > > _______________________________________________
> > > lttng-dev mailing list
> > > lttng-dev@lists.lttng.org
> > > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> > > 
> > 
> > 
> > -- 
> > 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.
> > 
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev@lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to disable an event that's been enabled by a wildcard selection or -a?
       [not found]   ` <5121EA9A.8080905@mentor.com>
@ 2013-05-02 13:40     ` Mathieu Desnoyers
       [not found]     ` <20130502134010.GF7035@Krystal>
  1 sibling, 0 replies; 9+ messages in thread
From: Mathieu Desnoyers @ 2013-05-02 13:40 UTC (permalink / raw)
  To: Woegerer, Paul; +Cc: lttng-dev

* Woegerer, Paul (Paul_Woegerer@mentor.com) wrote:
> Hi David,
> 
> On 02/14/2013 05:52 AM, David OShea wrote:
> > Hi,
> > 
> > My understanding (hopefully someone will correct me if I'm wrong) is that each time you invoke 'lttng enable-event', your specification for the events you want enabled is stored and applied, and/or potentially applied later if a new application connects to the session daemon.  All 'lttng disable-event' does is remove one of the specifications you previously provided to 'lttng enable-event', so you can't say 'enable-event *' and then 'disable-event foo:*' to get all events except 'foo:*'.
> > 
> > If you could constrain the application to use a particular trace provider name for all of its tracepoints, say "app", then you could just do 'lttng enable-event app:*'.  If you can't do that, then I think you need to fall back on getting a list of all the available tracepoints using 'lttng list -u', parsing this to find all of the available tracepoints, extracting the trace provider name from them, then using 'lttng enable-event <provider>:*' for each provider other than the provider from your uninteresting library.  I think there are APIs that can be used instead of issuing the 'lttng' commands.
> > 
> > I would certainly also like a way to be able to, say, enable all events other than foo:* and bar:* using one command.
> 
> I submitted a patch that does exactly this a while ago:
> http://lists.lttng.org/pipermail/lttng-dev/2012-June/018179.html
> 
> Although it's not upstream it works well for us.

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.

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'
lttng enable-event 'zc*'

->  !(abc* || cxx) || (a || c || zc*)

Am I correct ? If yes, we should expand lttng-tools lttng(1) manpage and
cmd help with this info.

Can you make sure it works well with lttng-ust master branch ?

Thanks,

Mathieu

> 
> Thanks,
> Paul
> 
> 
> > 
> > Regards,
> > David
> > 
> >> -----Original Message-----
> >> From: Ikaheimonen, JP [mailto:jp_ikaheimonen@mentor.com]
> >> Sent: Friday, 8 February 2013 7:56 PM
> >> To: lttng-dev@lists.lttng.org
> >> Subject: [lttng-dev] How to disable an event that's been enabled by a
> >> wildcard selection or -a?
> >>
> >> Consider the following scenario.
> >> I want to write a script that traces all UST tracepoints of a given
> >> application. I have no idea what the names of these tracepoints are.
> >> Also, I know that the application uses a library that contains some
> >> tracepoints I am not interested about. Now I want to trace all UST
> >> tracepoints except the ones I already know about. Is this possible with
> >> the lttng commands?
> >>
> >> If I enable all tracepoints with "lttng enable-event -u -a" I get all
> >> events, even those I do not want. I've tried using "lttng disable-
> >> event", and "lttng enable-event" with a filter, but I cannot seem to be
> >> able to get rid of the specific events.
> >>
> >> Thank you,
> >>
> >> JP Ikaheimonen
> >> Mentor Graphics Embedded Systems Division
> >> Nucleus(r) | Linux(r) | 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.
> >>
> >> _______________________________________________
> >> lttng-dev mailing list
> >> lttng-dev@lists.lttng.org
> >> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> > 
> > ----------------------------------------------------------------------
> > The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.
> > 
> > _______________________________________________
> > lttng-dev mailing list
> > lttng-dev@lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> > 
> 
> 
> -- 
> 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.
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to disable an event that's been enabled by a wildcard selection or -a?
       [not found] ` <20998D40D9A2B7499CA5A3A2666CB1EB19F968AF@ZURMSG1.QUANTUM.com>
@ 2013-02-18  8:47   ` Woegerer, Paul
       [not found]   ` <5121EA9A.8080905@mentor.com>
  1 sibling, 0 replies; 9+ messages in thread
From: Woegerer, Paul @ 2013-02-18  8:47 UTC (permalink / raw)
  To: David.OShea; +Cc: lttng-dev

Hi David,

On 02/14/2013 05:52 AM, David OShea wrote:
> Hi,
> 
> My understanding (hopefully someone will correct me if I'm wrong) is that each time you invoke 'lttng enable-event', your specification for the events you want enabled is stored and applied, and/or potentially applied later if a new application connects to the session daemon.  All 'lttng disable-event' does is remove one of the specifications you previously provided to 'lttng enable-event', so you can't say 'enable-event *' and then 'disable-event foo:*' to get all events except 'foo:*'.
> 
> If you could constrain the application to use a particular trace provider name for all of its tracepoints, say "app", then you could just do 'lttng enable-event app:*'.  If you can't do that, then I think you need to fall back on getting a list of all the available tracepoints using 'lttng list -u', parsing this to find all of the available tracepoints, extracting the trace provider name from them, then using 'lttng enable-event <provider>:*' for each provider other than the provider from your uninteresting library.  I think there are APIs that can be used instead of issuing the 'lttng' commands.
> 
> I would certainly also like a way to be able to, say, enable all events other than foo:* and bar:* using one command.

I submitted a patch that does exactly this a while ago:
http://lists.lttng.org/pipermail/lttng-dev/2012-June/018179.html

Although it's not upstream it works well for us.

Thanks,
Paul


> 
> Regards,
> David
> 
>> -----Original Message-----
>> From: Ikaheimonen, JP [mailto:jp_ikaheimonen@mentor.com]
>> Sent: Friday, 8 February 2013 7:56 PM
>> To: lttng-dev@lists.lttng.org
>> Subject: [lttng-dev] How to disable an event that's been enabled by a
>> wildcard selection or -a?
>>
>> Consider the following scenario.
>> I want to write a script that traces all UST tracepoints of a given
>> application. I have no idea what the names of these tracepoints are.
>> Also, I know that the application uses a library that contains some
>> tracepoints I am not interested about. Now I want to trace all UST
>> tracepoints except the ones I already know about. Is this possible with
>> the lttng commands?
>>
>> If I enable all tracepoints with "lttng enable-event -u -a" I get all
>> events, even those I do not want. I've tried using "lttng disable-
>> event", and "lttng enable-event" with a filter, but I cannot seem to be
>> able to get rid of the specific events.
>>
>> Thank you,
>>
>> JP Ikaheimonen
>> Mentor Graphics Embedded Systems Division
>> Nucleus(r) | Linux(r) | 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.
>>
>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev@lists.lttng.org
>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 
> ----------------------------------------------------------------------
> The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 


-- 
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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: How to disable an event that's been enabled by a wildcard selection or -a?
       [not found] <009B25148989C6458484484699278506985C0CFA@EU-MBX-01.mgc.mentorg.com>
@ 2013-02-14  4:52 ` David OShea
       [not found] ` <20998D40D9A2B7499CA5A3A2666CB1EB19F968AF@ZURMSG1.QUANTUM.com>
  1 sibling, 0 replies; 9+ messages in thread
From: David OShea @ 2013-02-14  4:52 UTC (permalink / raw)
  To: Ikaheimonen, JP, lttng-dev

Hi,

My understanding (hopefully someone will correct me if I'm wrong) is that each time you invoke 'lttng enable-event', your specification for the events you want enabled is stored and applied, and/or potentially applied later if a new application connects to the session daemon.  All 'lttng disable-event' does is remove one of the specifications you previously provided to 'lttng enable-event', so you can't say 'enable-event *' and then 'disable-event foo:*' to get all events except 'foo:*'.

If you could constrain the application to use a particular trace provider name for all of its tracepoints, say "app", then you could just do 'lttng enable-event app:*'.  If you can't do that, then I think you need to fall back on getting a list of all the available tracepoints using 'lttng list -u', parsing this to find all of the available tracepoints, extracting the trace provider name from them, then using 'lttng enable-event <provider>:*' for each provider other than the provider from your uninteresting library.  I think there are APIs that can be used instead of issuing the 'lttng' commands.

I would certainly also like a way to be able to, say, enable all events other than foo:* and bar:* using one command.

Regards,
David

> -----Original Message-----
> From: Ikaheimonen, JP [mailto:jp_ikaheimonen@mentor.com]
> Sent: Friday, 8 February 2013 7:56 PM
> To: lttng-dev@lists.lttng.org
> Subject: [lttng-dev] How to disable an event that's been enabled by a
> wildcard selection or -a?
> 
> Consider the following scenario.
> I want to write a script that traces all UST tracepoints of a given
> application. I have no idea what the names of these tracepoints are.
> Also, I know that the application uses a library that contains some
> tracepoints I am not interested about. Now I want to trace all UST
> tracepoints except the ones I already know about. Is this possible with
> the lttng commands?
> 
> If I enable all tracepoints with "lttng enable-event -u -a" I get all
> events, even those I do not want. I've tried using "lttng disable-
> event", and "lttng enable-event" with a filter, but I cannot seem to be
> able to get rid of the specific events.
> 
> Thank you,
> 
> JP Ikaheimonen
> Mentor Graphics Embedded Systems Division
> Nucleus(r) | Linux(r) | 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.
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2013-08-20  9:27 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-08  9:25 How to disable an event that's been enabled by a wildcard selection or -a? Ikaheimonen, JP
     [not found] <009B25148989C6458484484699278506985C0CFA@EU-MBX-01.mgc.mentorg.com>
2013-02-14  4:52 ` David OShea
     [not found] ` <20998D40D9A2B7499CA5A3A2666CB1EB19F968AF@ZURMSG1.QUANTUM.com>
2013-02-18  8:47   ` Woegerer, Paul
     [not found]   ` <5121EA9A.8080905@mentor.com>
2013-05-02 13:40     ` Mathieu Desnoyers
     [not found]     ` <20130502134010.GF7035@Krystal>
2013-05-02 14:00       ` Mathieu Desnoyers
2013-05-03 10:40       ` Woegerer, Paul
     [not found]       ` <51839435.8010607@mentor.com>
2013-05-07 14:15         ` Mathieu Desnoyers
     [not found]         ` <20130507141558.GD5118@Krystal>
2013-08-16 12:08           ` Ikaheimonen, JP
     [not found]           ` <009B25148989C6458484484699278506E5385F9C@EU-MBX-01.mgc.mentorg.com>
2013-08-20  9:27             ` Woegerer, Paul

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.