This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: [Perftools]hello world
- From: Martin Hunt <hunt at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Fri, 15 Jul 2005 12:35:19 -0700
- Subject: Re: [Perftools]hello world
- Organization: Red Hat Inc.
- References: <20050714184801.GG24787@redhat.com> <mailman.1121414761.2945.perftools-list@redhat.com> <y0mu0iwp0q9.fsf@toenail.toronto.redhat.com>
On Fri, 2005-07-15 at 11:06 -0400, Frank Ch. Eigler wrote:
> [moving to systemtap@]
>
> hunt wrote:
>
> > [...]
> > On July 8th, I made some changes to the runtime that are inconsistent
> > with what the translator generated.
> > [...]
>
> In general, the module startup/shutdown logic needs to be agreed upon.
> I would prefer it if the translator-generated output "owned" the sole
> low-level module init/exit hooks, and called into the runtime as
> appropriate, and not vice versa.
If you don't like the way the runtime does something, you have two
options; write your own or change the way the runtime function works.
I'd be happy to help with either. You can, of course, put everything in
the translator if you have enough time and don't mind the added
complexity.
> Similarly, the probe handler entry/exit code will get more complicated
> shortly as I add reentrancy, session startup/shutdown, and other such
> logic to the translator's output.
There is nothing in the runtime to handle these. In fact I'm not sure
what you mean by them. The runtime currently has no common probe handler
entry/exit code.
> Likewise, stp_exit may be a bit
> half-baked for the more complex lifecycle cases, like probes being
> concurrently executed elsewhere. Let's leave this stuff to the
> translator to worry about too.
OK, but what are you talking about when you say "probes being
concurrently executed elsewhere"? The only way probes can execute
concurrently is on a multiprocessor system. What has this to do with
stp_exit?
Martin