Suppose we do something like this (edited for brevity):

$ lttng enable-event -u sample:message --loglevel notice
$ lttng list session
Events:
  sample:message (loglevel: TRACE_NOTICE (5)) [enabled]
$ lttng disable-event -u sample:message
$ lttng list session
Events:
  sample:message (loglevel: TRACE_NOTICE (5)) [disabled]
$ lttng enable-event -u sample:message
$ lttng list session
Events:
  sample:message [enabled]
  sample:message (loglevel: TRACE_NOTICE (5)) [disabled]
$ lttng enable-event -u sample:message --loglevel err
$ lttng list session
Events:
  sample:message [enabled]
  sample:message (loglevel: TRACE_NOTICE (5)) [disabled]
  sample:message (loglevel: TRACE_ERR (3)) [enabled]

This could be understood to mean that sample:message will be logged unless its 
loglevel lies in the TRACE_WARNING (4) to TRACE_NOTICE (5) range.  But that is 
not what lttng is doing: it looks up all the rules which match the candidate 
event, then ORs the results together.  (Two rules are different if their string 
key or loglevel setting are different; currently lttng treats a loglevel-only 
setting as it it matched the corresponding loglevel setting)  So in this case 
there is no way that sample:message could not be logged, since the first "rule" 
(i.e. sample:message [enabled]) trumps the others.

Wouldn't it be much clearer if the enable-event command did some clean up in 
the list of rules?  The previous use case would then become:

$ lttng enable-event -u sample:message --loglevel notice
$ lttng list session
Events:
  sample:message (loglevel: TRACE_NOTICE (5)) [enabled]
$ lttng disable-event -u sample:message
$ lttng list session
Events:
  sample:message (loglevel: TRACE_NOTICE (5)) [disabled]
$ lttng enable-event -u sample:message
$ lttng list session
Events:
  sample:message [enabled]
$ lttng enable-event -u sample:message --loglevel err
$ lttng list session
Events:
  sample:message [enabled]

In other words, we have a partial ordering on the loglevel key that goes:
LTTNG_EVENT_LOGLEVEL_ALL > LTTNG_EVENT_LOGLEVEL_RANGE(m),
LTTNG_EVENT_LOGLEVEL_ALL > LTTNG_EVENT_LOGLEVEL_SINGLE(n),
LTTNG_EVENT_LOGLEVEL_RANGE(m) > LTTNG_EVENT_LOGLEVEL_SINGLE(n) if m>=n

It is tempting to extend the partial ordering to the text key, but I think we 
then need to change the interpretation of the rules from a simple "OR":

$ lttng enable-event -u "sample:mes*"
$ lttng list session
Events:
  sample:mes* [enabled]
$ lttng enable-event -u sample:message
$ lttng list session
Events:
  sample:mes* [enabled]
$ lttng disable-event -u sample:message
$ lttng list session
Events:
  sample:mes* [enabled]
  sample:message [disabled]

The user's wish of "enabling sample:mes* except for sample:message" would be 
achieved if the daemon treated the disabling rules as having priority over the 
enabling ones.  Instead of having a single list with each list entry having an 
enabled/disabled attribute, the daemon would need to maintain two lists, one 
for enabling rules, the other for disabling rules (and the list entries of both 
lists would be attribute-less).

This approach would dovetail nicely with the proposed exclusion special 
character (!).  A command like:

$ lttng enable-event -u "sample:mes*" "!sample:message"

Would readily be resolved as an entry in each list.

But then how could we deal with:

$ lttng disable-event -u "sample:mes*" "!sample:message"

(In other words, "disabling sample:mes* except for sample:message")  Maybe we'd 
need two sets of disabling rules: a weak one (enabling rules have priority) and 
a strong one (enabling rules don't have priority).  Although that could still 
be reasonably understandable when displayed with 'lttng list session' if the 
rules were presented in three ordered blocks (strong disabling rules, enabling 
rules, weak disabling rules), I suspect the scheme is getting too complex.

This needs more thought.   :-)

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
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Reply via email to