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
