This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Notes from the systemtap BOF
- From: Michael Raymond <mraymond at sgi dot com>
- To: Karim Yaghmour <karim at opersys dot com>
- Cc: "Spirakis, Charles" <charles dot spirakis at intel dot com>, systemtap at sources dot redhat dot com, Vara Prasad <prasadav at us dot ibm dot com>, Mathieu Desnoyers <compudj at krystal dot dyndns dot org>, bert hubert <bert dot hubert at netherlabs dot nl>
- Date: Wed, 27 Jul 2005 09:03:07 -0500
- Subject: Re: Notes from the systemtap BOF
- References: <2CB9B46A0690824693581340E23B4E1004A4AF6A@scsmsx401.amr.corp.intel.com> <42E64BD7.8020809@opersys.com>
On Tue, Jul 26, 2005 at 10:42:31AM -0400, Karim Yaghmour wrote:
> Actually, I've been thinking about this further and I've got it down to
> something like (avoiding the word "trace" altogether):
> evmarker(EVENT_TAG, EVENT_HANDLERS, EVENT_NR, PARAM/TYPE, ...)
>
> Notice that I got rid of the EVENT_ID. Instead, I think events should be
> indentified by a concatenation of:
> - The full path to the file inside the kernel tree (ex.:kernel/sched.c)
> - The name of the function where they are located (ex.:schedule())
> - The order in which they are located inside that function.
> So, for example, the identifier of the lone marker inside schedule() for
> the scheduling change would be something like:
> "kernel/sched.c:schedule:1"
> The actual "ID" could be something like an md5 based on that string.
> Correlation between IDs and original string (the actual event) would be
> done in user-space.
IMHO event markers have meaning separate from their physical location.
If we have two markers within schedule() and I add an ad hoc one, it
shouldn't change the "identity" of the previous two.
I think that each trace point should have a numeric ID and a textual
component associated with it. Whether the textual part comes from the
kernel or is linked to the ID in some user space DB is of minor importance.
The ID by itself allows position independence and quick comparison. It also
allows ranges to be enabled / disabled which seems more semantically correct
than a per-file approach. The text by itself gives human readable meaning.
If we go with both of them than we should have a policy regarding the
normalization issues associated with their tuple.
Thanks,
Michael
--
Michael A. Raymond Office: (651) 683-3434
Core OS Group Real-Time System Software