This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Perftools]hello world


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]