Minutes of 4/28/05 meeting

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

Minutes of SystemTAP Conference Call, April 28, 2005

Participants:
IBM:
	Larry Kessler (lkessler@us.ibm.com -- Beaverton, OR)
	Vara Prasad (varap@us.ibm.com -- Beaverton)
	Jim Keniston (jkenisto@us.ibm.com -- Beaverton)
	Hien Nguyen (nguyhien@us.ibm.com -- Beaverton)
	Ananth Mavinakayanahalli (amavin@redhat.com, ananth@in.ibm.com --
Boston)
	Prasanna Panchamukhi (prasanna@in.ibm.com -- Bangalore)
	Maneesh Soni (maneesh@in.ibm.com -- Bangalore)
	Tom Zanussi (trz@us.ibm.com -- Chicago)
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)
	Rusty Lynch (rusty@linux.co.intel.com -- Hillsboro, OR)
	Anil KeshavaMurthy (anil.s.keshavamurthy@intel.com -- Hillsboro)

Actions Required (ARs):
1. All: Review recent changes to archpaper/systemtap.tex.

2. All: Give Brad suggestions re: the test plan.

3. Will: Reply to Masami Hiramatsu regarding Hitachi's offer re:
SystemTap/LKST collaboration.

4. Jim: Is __builtin_return_address() used for anything vital?

5. Frank: Post a description of his reentrant-probe concern(s).  [DONE]

6. Ananth: Investigate Frank's reentrant-probe concern(s).

7. Frank: Propose a vehicle for a SystemTap problem tracking system.
[DONE]

8. Jim: Post a summary of feedback from our prospective VM tapset
author.

We reviewed action items from the 4/20 meeting in Santa Clara:

- Stack - "minimal stack usage" vs. alternate stack for kprobes [Jim]
No progress worth mentioning.

- container/keys larger than long for associative array indexing?
[Martin]
Should be no problem if we agree to go with 64-bit keys.

- Security model - user transport [Martin]
Still no plans to do before U2.

Doug Armstrong (Intel) is working on the synchronization tapset.

- Post presentation slides to systemtap@sources.redhat.com. [All]
Most slide sets from the 4/20 meeting have been posted, but the Intel
guys are awaiting internal permission to post theirs.

- Finish updating the Language Reference section of systemtap.tex. [Jim]
Frank has checked in a bunch of changes and restructured the document.
Jim will sync his local changes with the updated doc.

- Update the Kernel-to-user Transport section. [Martin]
Done.

- Update the Tapsets section. [Frank]
This is in progress.

- Write the Kprobes sections. [Jim]
Will do now that kprobes enhancements seem to be settling down.

- Post notes from the task-list review. [Elena]
She thought she did, but it didn't take.

Intel is making progress on the Itanium port of kprobes.

Brad is working on the test plan.  He is open to advice.

Red Hat has assigned a tech writer to do a SystemTap user's guide.
This writer will need support -- e.g., reviews of the guide.

Will will do a presentation of SystemTap and oprofile at the Red Hat
Summit in New Orleans June 1-3.  Slides are due May 6.

OLS will be July 20-23.  The deadline for Will and Vara's paper is now
May 15.

Masami Hiramatsu, LKST developer, has offered to help.  Will will
follow up.  Will analyzed LKST's instrumentation points and posted a
summary 3/7/05, but Masami says the instrumentation has changed.
Frank would like to see this information arranged according to the
template he posted.

Jim reported that a prospective tapset developer was leery of the
template and of the proposed systemtap language.  (He's happy with
kprobes/jprobes, so far.)  Jim will post a summary of these comments.
Frank says the template doesn't need to be completed in full.  It's fine
to allow somebody to develop instrumentation using kprobes, and then
use that as the starting point for a SystemTap tapset.

The main remaining issue with return probes is the fact that
this implementation will break __builtin_return_address().  Is
__builtin_return_address() used for anything besides instrumentation
and debugging?  If so, we should just document this limitation.
Jim will investigate.

Frank has a concern about what happens when a probe handler hits
a probepoint.  There's disagreement about what actually happens.
Frank will post a description of the problem.  Ananth will
investigate.

We need a problem-tracking system.  Red Hat's bugzilla is not
acceptable because of limited access by non-Red-Hat developers.
bughost.org was suggested.  For components that are already
in the kernel (e.g., kprobes), use Bugme.  Frank will investigate.

Vara's 4/27 request for instrumentation that would allow us to
determine which return statement caused a return was discussed.
It doesn't look feasible.