[lttng-dev] Enabling and disabling events

[Thibault, Daniel]

> De : Ikaheimonen, JP [mailto:jp_ikaheimonen at mentor.com] 
> Envoyé : 10 septembre 2013 07:41
>
> As you can see, things easily get too complicated.
>
> Currently in LTTng you can only disable events that are enabled in the first place. In other words, an event is born disabled, as if 'lttng disable-event "*"' had been issued whenever a > channel is created. We already have a mechanism to un-disable events - this is the enable-event command. I do not see any reason to add another command to do exactly what
> enable-event already does. If we want to 'disable all events except 'a'' we can call lttng enable-event 'a'. Symmetrically, I would like to have 'enable all events except 'a'', but
> currently this is impossible.

   I disagree with the perception that "an event is born disabled".  I perceive quite the opposite, in fact.  The problem, as I've mentioned elsewhere before, is that enable-events is a double-duty command, which serves to both *create* (i.e define) events and to toggle their enablement.  I would much rather have a separate define-event command.  Right now you can define, enable, disable until the trace is started, and once that has happened you can only enable and disable.  With separate define-event and enable-event commands the code would be simpler (and thus less bug-prone), and so would the user experience.

   Getting back to event birth, events are initially non-existent, then they transition to defined (and enabled), and can later toggle between enabled and disabled (but cannot be undefined).  It is in that sense that they are born enabled.

> I still propose keeping the disable-event and enable-event commands asymmetrical. Based on your thoughts below, I also suggest keeping two lists for the enabled events: one for > the enablements, and one for the exceptions to the enablements. The items in the latter list would point to specific items in the former list, so that the exceptions would be tied to > certain enablements.
>
> So for instance,
>
> $ lttng enable-event -u 'x'
> $ lttng list session
> Events:
>   x [enabled]
> $ lttng enable-event -u "x*" --except "xa*"
> $ lttng list session
> Events:
>   x [enabled]
>   x* [enabled, exception xa*]

   I think the exception should be in the event_name string (recall that enable-event accepts a *list* of event_names), something like:
$ lttng enable-event -u "x*!xa*"
$ lttng enable-event -u "x*!xa*","y*!yy*"
   (Presumably, if an '!' appears in an actual event name, it would need to be escaped in the event_name argument of enable-event)

> $ lttng enable-event -u "x*" --except "xb*"
> $ lttng list session
>   x [enabled]
>   x* [enabled, exception xa*]
>   x* [enabled, exception xb*]
>
> Again, all the enablements would be checked, and the event would be enabled if any of the enablements match.

   What if the user types lttng enable-event -u "xa*!x*"?  Clearly the argument collapses to an empty string (it does not enable anything), so the interface should leave the current list of enablements and disablements alone, and issue a warning to the user.

> If an event enablement has an exception, it must be used in the disable-event command also:
> $ lttng disable-event -u "x*" --except "xb*"
> $ lttng list session
>   x [enabled]
>   x* [enabled, exception xa*]
>   x* [disabled, exception xb*]

   I don't like that restriction at all.  You should be able to use any argument for either enable-event or disable-event.

> Comments are very welcome.
>
> JP Ikaheimonen | SW Development Engineer http://go.mentor.com/sourceryanalyzer

   I still say the lttng daemon should process the resulting enablement/disablement sets to simplify them whenever possible.  Thus:

$ lttng enable-event -u 'x'
$ lttng list session
Events:
   x [enabled]
$ lttng enable-event -u "x*!xa*"
$ lttng list session
Events:
   x* [enabled, exception xa*]

   The 'x [enabled]' rule is removed because it is subsumed by the 'x* [enabled, exception xa*]' rule.

$ lttng enable-event -u "x*!xb*"
$ lttng list session
  x* [enabled]

   In this case the union of "x*!xa*" and "x*!xb*" results in "x*".

   If the user wants to do "all events beginning with x except for those beginning with xa or xb", we would have to accept the '[]' regular expression operator (e.g. enable-event "x*!x[ab]*) (but note that the '*' is a wildcard here, not the regular expression repetition operator).  It may be easier to go to full-blown regular expressions.

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