Minutes of 7/28/05 meeting

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

Minutes of SystemTap Conference Call, July 28, 2005

Participants:
IBM:
	Larry Kessler (lkessler@us.ibm.com -- Beaverton)
	Vara Prasad (varap@us.ibm.com -- Beaverton)
	Jim Keniston (jkenisto@us.ibm.com -- Beaverton)
	Hien Nguyen (nguyhien@us.ibm.com -- Beaverton)
	Kevin Stafford (kevinrs@us.ibm.com - Beaverton)
	Tom Zanussi (trz@us.ibm.com -- Chicago)
	Ananth Mavinakayanahalli (amavin@redhat.com, ananth@in.ibm.com --
Boston)
	Prasanna Panchamukhi (prasanna@in.ibm.com -- Bangalore)
Red Hat:
	Elena Zannoni (ezannoni@redhat.com -- Boston)
	Will Cohen (wcohen@redhat.com -- Raleigh)
	Martin Hunt (hunt@redhat.com -- Seattle)
	Frank Eigler (fche@redhat.com -- Toronto)
	Graydon Hoare (graydon@redhat.com)
Intel:
	Charles Spirakis (charles.spirakis@intel.com)
	Rusty Lynch (rusty.lynch@intel.com -- Hillsboro)
	Anil KeshavaMurthy (anil.s.keshavamurthy@intel.com -- Hillsboro)
Hitachi:
	Satoshi Oshima

Actions Required (ARs):
>From 5/19/05:
19. Vara: Collect sample kprobes modules and post them to the
SystemTap web site.

22. Rusty: Look into x86_64 limitation re: temporary disarming of
reentrant probes.

23. Jim, Martin: Ensure that the runtime's stack-trace feature works
appropriately when there are return probes in the call stack.
[Update: Martin is working on this.  Jim will prototype an improvement
whereby the saved IP is updated before the handler is called.]

>From 6/9/05:
26. Rusty/Brad: Forward email address of Intel test person to Jay
Turner.  [Update: As of 7/7/05, Brad hasn't done this.  Did Rusty?]

>From 6/23/05:
30. Rusty: Review Will's rendition of Rusty's test that exercises
probes on a wide variety of instruction types.  [Update: As of 7/7/05,
Will still needs to hear back from Rusty.]

31. Anil: Publish description of problem and solution regarding ia64
probes set on slot 1 of a bundle.

34a. Satoshi: Post description of LKST team's idea for a new approach.
[DONE: djprobes proposal posted 7/13/05 by Masami Hiramatsu]

36. Jim: Create and submit Documentation/kprobes.txt writeup.
[Update 7/28/05: Tying up one more loose end before posting to LKML.]

>From 6/30/05:
37. Vara: Publish C Tapsets Rev 3.
[CANCELLED: C-only tapsets are not needed now that script tapsets
can include calls to C functions.]

>From 7/7/05:
38. Kprobes developers: Update status document
(htdocs/kprobes-status.html in CVS). [DONE]

39. Ananth: Summarize the status of the ppc64 runtime port for Martin.

40. Ananth, Will: Port the probe-all-instruction-types test to ppc64.

>From 7/28/05:
41. Anil: Post a summary of known djprobes implementation issues.

Several OLS attendees reported on the conference.  The SystemTap
presentation was well received.  Vara's BOF was well attended and
sparked some interesting discussion.  (See Charles's notes posted
7/26.)

Charles hosted a BOF on perfmon/perfctr/oprofile.  Charles will
post the minutes to the perfctr mailing list.  Andrew Morton wants
to see the issues discussed.  There was no flame war at the BOF,
but the topic has been known to draw flames.  Elena offered that Red
Hat will host a new mailing list if necessary.  Vara reported that
he'd heard that perfmon was overcomplicated due to its many features.
Different people use different features, said Charles.  A technical
discussion would help clarify the necessary feature set.

Rusty reported some interest in using kprobes/SystemTap for fault
injection.  At least one potential user expressed disappointment
that jprobes doesn't allow you to change the values of the probed
function's args.  (The ia64 port actually DOES allow this.)  Vara
explained that Linus asked for this restriction.

Anil reported that Bert Hubert would like to see arg values upon
return from a function.  Jim pointed out that this would be tough to
do reliably in kprobes, since the ABIs specify where the args live
on entry to the function, but not on exit.  It could perhaps be done
in SystemTap, which has access to the debug info.

Anil will post a summary of djprobes implementation issues.  Rusty
opined that because of the number and nature of the restrictions on
where a djprobe can be inserted, these restrictions must be enforced in
user space; the kernel code can't realistically be made smart enough.
Vara: So is djprobes too fragile to be accepted into the kernel?
Rusty: Not necessarily, since it doesn't touch anything else.

Martin is investigating an apparent bug in the runtime's kernel-user
transport.  It might be a relayfs bug.  Tom will help him investigate.

Red Hat can now package the translator system as an RPM, but it's not
ready for general consumption.  Milestones were discussed; Elena will
communicate this info to those with a need to know.