This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: proposed instruction trace support in SystemTap
- From: grundym at us dot ibm dot com (grundy)
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: dcnltc at linux dot vnet dot ibm dot com, systemtap at sourceware dot org
- Date: Fri, 6 Jul 2007 08:46:19 -0400
- Subject: Re: proposed instruction trace support in SystemTap
- References: <4689826A.9040902@us.ibm.com> <y0mabuar6ap.fsf@ton.toronto.redhat.com>
On Thu, Jul 05, 2007 at 03:37:02PM -0400, Frank Ch. Eigler wrote:
> Particularly, to turn the probe on and off by explicit function calls.
> <snip>
> Regarding semantics, this is tricky business. Turning off active
> probes is relatively simple, because even if the underlying probe API
> doesn't support instantaneous (atomic) disarming, we can simulate it
> until the API catches up (by adding an "am I supposed to be disarmed?"
> conditional to the handler). Turning them *on* is different - we
> can't help but possibly miss a couple of events as the API catches up.
Maybe we could support two levels of disarmed? One would be probepoints
removed as discussed, the other could be probe points in, complete
handler not firing (just enough to say "we're not active" and return).
In tapscripts what I will do sometimes is have an active variable that
gets checked at the beginning of every handler. When the trigger is hit
to start recording, the variable is changed and recording begins. It
would be good to have a way to be sure that when you activate a set of
probes, that they are actually active and not on the way to being
active.
Thanks
Mike