Minutes of 3/31/05 meeting

[Jim Keniston <jkenisto at us dot ibm dot com>]

Minutes of SystemTAP Conference Call, March 31, 2005

Next meeting: April 7, 2005 9:00 am Pacific Time
NOTE THE TIME CHANGE from 9:15 to 9:00.  Also note that we in the US and
Canada "sprang forward" to Daylight Saving Time on 4/3/05.

Participants:
IBM:
	Larry Kessler (lkessler@us.ibm.com -- Beaverton, OR)
	Vara Prasad (varap@us.ibm.com -- Beaverton)
	Jim Keniston (kenistoj@us.ibm.com -- Beaverton)
	Hien Nguyen (nguyhien@us.ibm.com -- Beaverton)
Red Hat:
	Will Cohen (wcohen@redhat.com -- Raleigh)
	Frank Eigler (fche@redhat.com -- Toronto)
	Martin Hunt (hunt@redhat.com -- Seattle)
	Elena Zannoni (ezannoni@redhat.com -- Boston)
	Andrew Cagney (cagney@redhat.com -- ???)
Intel:
	Brad Chen(brad.chen@intel.com -- Santa Clara)
	Douglas ______  (Sorry, I didn't catch the name.)

Actions Required (ARs):
1. All: Review Brad's safety paper redux.

2. Vara: Check in additions to the architecture/design paper. [DONE]

3. All: Review Vara's additions to the architecture/design paper.  Add
text in your areas of expertise.

4. Jim: Write a description of the systemtap language (as currently
implemented by the parser) for the architecture/design paper. [DONE]

5. Brad: Given review comments, update the safety paper and add an
appropriate subset to the architecture/design paper.

6. Hien: Re-post return-probes patch on LKML when there's a good excuse
to do so.

7. Vara: Pass along IBM-internal suggestions regarding return-probes
patch to Hien.  [DONE]

8. Will (and others welcome): Post to LKML in support of the
return-probes patch when Hien republishes it.  [Awaiting re-post]

9. Jim: Re-ignite the discussion of how to express (in the systemtap
language) and implement access to the probed function's context from
within a probe handler.

10. Frank: Pass along further thoughts to Jim on AR #9. [DONE]

The main goal of today's meeting is to identify, and plan to fill, any
holes remaining in the initial SystemTap offering.

Brad has published a redux of his safety paper.  Please review it.  [AR
#1]

Vara has begun the process of fleshing out the architecture paper and
converting it to a design document.  He will check in his version.  [AR
#2 -- DONE: Rev 1.8 of archpaper/systemtap.tex).  Please review his
changes and flesh out sections where you can.  [AR #3]

Jim volunteered to document the systemtap language as currently
implemented in the parser.  [AR #4 -- DONE: systemtap.tex Rev 1.9]

Should Brad's safety paper be added to the design doc?  Brad will accept
review comments and add an appropriate subset to the design doc.  [AR
#5]

Hien has posted his return-probes patch to LKML.  No comments so far. 
Hien will re-post when there's a good excuse to do so.  [AR #6] Vara
will pass along some comments from IBM people.  [AR #7]  Since SystemTap
needs this feature, SystemTap engineers should post in support of it
when Hien re-posts.  Will, at least, will do so.  [AR #8]

Tapsets are not well defined yet.  Some discussion of this.

There was discussion of accessing the probed function's context (and
kernel data structures in general) from a SystemTap handler script. 
Frank wants a firewall between the scripting language and the kernel.

Martin is deferring work on the part of the runtime that implements the
kernel->user data hose.  Tom Z hasn't been able to work on SystemTap the
past couple of weeks, but should be back next week.  Frank is not
convinced that optimizing the performance of the kernel->user hose is
important.

Is it time to start a daily build and test-suite run?  I think the
answer was "not yet."

Do we have a "driver" command that manages all the steps (parsing,
elaboration, code generation, execution, output)?  No, that's down the
road a ways.  We need to hand-crank some sample tapsets: system calls,
scheduler, I/O, VM.  Who owns this task?  Still Vara.  One example is
Will's I/O probe set, posted on the SystemTap list ("kprobe example
watching block device access"?).

Much discussion about who could help out with tapsets.  The Red Hat
folks are busy elsewhere.  Ananth?  He should have his "multiple
handlers at same address" feature complete in a few weeks.  [Prototype
posted 4/1/05.] The scalability effort (e.g., smarter locking) is more
open-ended.

Elena had news on the U2 code freeze.  Red Hat will feature SystemTap as
a technology preview.  We need to define what we'll deliver in U2.  What
else needs to be done before then?  There's still a lot to define in
terms of access to the probed function's context and other kernel data
structures.  There are a lot of ideas, but no solid design.  Jim will
try to revive and drive this discussion.  [AR #9] Frank has some further
ideas, and will send them along to Jim.  [AR #10]

What do we need in the base by U2?  Multiple probes at same address? 
This isn't needed for return probes (even if we want to support
independent register/unregister of return probes).  But we'll eventually
need it because of overlapping tapsets.  We also may want group
start/stop for probes.

IBM will send a couple of people [Vara and Jim] down to Mt. View to meet
with Will, Frank, and Martin on 4/20.  Elena will be available
part-time.

Martin would like some help on the runtime -- e.g., code review.

Our start time will move to 9:00 am during US/Canada DST, to give
Prasanna a better chance to join us.