Potential Systemtap topics for the Kernel Summit

[Theodore Tso <tytso at mit dot edu>]

On Wed, Jul 02, 2008 at 03:25:19PM -0400, Frank Ch. Eigler wrote:
> So, one way a kernel developer could help write a tapset piece for us
> is to encapsulate this into a tapset script fragment:
> 
> probe vfs.read = kernel.function ("vfs_read")
>   {
>     dev_nr = $...expression
>     inode_nr = $...expression
>   }
> 
> ****  or  ****
> 
> Kernel maintainers could add a marker or two right into their C code:
> 
> {
>     /* ... */
>     trace_mark (vfs_read, "dev %u inode %u whatever %s",
>                           expression1, expression2, whatever);
>     /* ... */
> }

So it sounds like potential Systemtap topics for the kernel summit
might include:

A)  Enhancements to kbuild to better support kernel developers who want
to use systemtap.

B) Discussion of list of tapsets and markers that would be useful for
System administrators wanting to use systemtap.  This is one place
where if someone could volunteer to examine some of the Dtrace
examples and blog entries where Dtrace users have raved about how
Dtrace saved their bacon by instantly identifying some performance
problem, and then assemble a "tapset or marker WANTED" bounty list,
that would be very useful.  One potential problem is that I suspect
kernel developers may not know or have the intuition of what sort of
markers or tapsets would be most useful.  Having a targetted wish list
would be very useful.  (We might then have some discussions about
whether a particular tapset or marker is too hard to maintain, or
represents too much of a performance hit, but at least would be
dealing with concrete requests.)

C) Whether tapsets/markers should be maintained inside the kernel, and
if so, how.

D) What is the right way to do user probes.

Of course, if some of these topics are handled via e-mail before the
kernel summit, even better.  But somehow, I'm guessing there will
still be more to talk about.  :-)

The bottom line is more communication between the kernel and systemtap
developers is a good thing (and getting more kernel developers to use
systemtap would be a good start).  And I do want to make sure I get
across that I wasn't trying to imply that all of the work and changes
should happen on the systemtap side.  In fact, if you look at some of
the topics that have come up on this thread, more than few of them
involve changes in the kernel side....

Does this sound reasonable?

					- Ted