Hi Daniel, I can see your point about how the events are created. I do not completely agree with your views, but it is not essential that I do.
How about the following (this is based on the ideas you have brought forth): We keep the enable-event command as it is. However, we enhance the event name specification syntax somewhat. We could of course do a full regex matching, but I fear that would get too slow. Instead we'd have something like $ lttng enable-event -u "*!mine*!alsomine" This would enable any event ('*'), except those who match with mine* or alsomine. The matching logic would separate the name specification into parts, using the ! character as a separator. If the new event name matches the first part but does not match any of the latter parts, then the event gets enabled. I don't like collating the event enablers into unified specifications. I'd like to have each enable-event command create its own entries into the enabler list. I feel a bit uneasy if the event enabler code gets too sophisticated. I'm still unsure how the disable-event command should work. I'm playing around with the idea that the event specification in the disable-event command should exactly match the event specification given in the enable-event command. It does not feel good, but any solution around it seems to bring about the ideas about disable-lists which I would like to avoid. Cheers, JP Ikaheimonen | SW Development Engineer http://go.mentor.com/sourceryanalyzer Mentor Embedded(tm) | 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