This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: architecture paper draft
- From: William Cohen <wcohen at redhat dot com>
- To: "Chen, Brad" <brad dot chen at intel dot com>
- Cc: Vara Prasad <prasadav at us dot ibm dot com>, systemtap at sources dot redhat dot com, "Frank Ch. Eigler" <fche at redhat dot com>
- Date: Thu, 31 Mar 2005 12:10:38 -0500
- Subject: Re: architecture paper draft
- References: <75EC4D5486CAC247B84AAAA6F96AA558039D7574@orsmsx402.amr.corp.intel.com>
Chen, Brad wrote:
Vara has identified two basic kinds of taps:
- program-counter based
- interrupt based
Additional ones to think about:
-data memory locations accesses
track changes to value or determine functions modifying val
use hardware support in processor to watch location
-taps based on function pointers in data structures
lots of the ABIs in the kernel use data structures to describe operations.
These makes sense from the perspective of the Systemtap
implementor. From the perspective of the script writer,
they will likely be thinking about source-code constructs
rather than machine code:
- procedures (before, after, etc.). This is the "systemtapset", right?
- source-code features (call sites, line numbers, labels)
- software events (synchronous)
- hardware events (asynchronous)
I think the first three would be program-counter based and
the fourth would be interrupt based. So part of the design
ought to be considering both the implementation perspective
and the constructs that script writers would think about.
A third type I'd add to Vara's list is "compound taps".
For example, a subset of scheduler-related taps from the
systemtapset might be used as a part of the scheduler
tap set. You might also have a compound tap that was a
existing tap plus a condition, such as a procstatechange()
event when NewState==PROC_READY.
Brad