----------------------------------------------------------------------
> Date: Fri, 16 Aug 2013 12:08:56 +0000
>
> 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 ?
>
> JP Ikaheimonen
> Mentor Graphics
----------------------------------------------------------------------
The second command should definitely disable event 'ab'. Otherwise the
effect of any given command sequence becomes undefined because the system is
'too stateful'.
----------------------------------------------------------------------
> Date: Tue, 20 Aug 2013 11:27:46 +0200
>
> 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 Woegerer, SW Development Engineer
----------------------------------------------------------------------
It makes little sense to me that the sequence:
# lttng enable-event "!ab" -u
# lttng enable-event "a*" -u
should "enable all events except 'ab'" (the original intent). There would be
no way of ever turning 'ab' back on, unless the command treated the wild card
differently from its equivalent expansion. To illustrate my point, assume the
alphabet consists of just {a, b, c}; then "a*" expands to "aa", "ab", "ac",
"aaa", "aab", etc. Issuing the command with the "a*" argument or its
equivalent expansion (which is possible here since event names are
length-limited) should yield the same result.
I note that the "!" special character was not used in older versions of
enable-event, leading to limited backward compatibility of this new interface
convention. Is the intent to remove the disable-event command entirely?
Daniel U. Thibault
Protection des systèmes et contremesures (PSC) | Systems Protection &
Countermeasures (SPC)
Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber
Security (MCCS)
R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D
Canada - Valcartier (DRDC Valcartier)
2459 route de la Bravoure
Québec QC G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada | Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
