> De : Ikaheimonen, JP [mailto:jp_ikaheimo...@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/> _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
