Re: Systemtap for NFSv4

[Gerrit Huizenga <gh at us dot ibm dot com>]

On Wed, 23 Aug 2006 12:10:55 EDT, Trond Myklebust wrote:
> On Wed, 2006-08-23 at 08:43 -0700, Gerrit Huizenga wrote:
> > Trond, Trond, Trond:  My answers are basically pfeh, Pfeh, and PFEH!
> 
> "...Your mother was a hamster, and your father smelt of ELDERBERRIES!"
>        (Monty Python's Search for the Holy Grail)

Heh heh - so you met my parents!  Kewl!

> > :)
> > 
> > Comments interspersed...
> 
> Ah, but you appear to be missing an important point. Tony was asking if
> we wanted to _replace_ the current set of dprintk()s with systemtap. I'm
> just saying that I'm not going to start throwing dprintks until we have
> a viable replacement. SystemTap is not (yet?) convincing as a candidate
> for that role.
 
I'm not convinced that I'm missing the point.  I think this is a
good question to start thinking about.  Ultimately, if you can do
the same thing (and more) with SystemTap than you can do with static
probe points, and all dprintk()'s are macro replaced with SystemTap
static probe points, you might have a try-before-you-buy and general
validation approach.  Not sure if that is completely feasible today
but might be a cheap option.

> Note: if we do want to replace dprintks with SystemTap, then I think
> that another precondition would be that we include the main systemtap
> debugging scripts in Linus' tree.

That has also been discussed - and I think that is a valid proposal.
Not sure what the current status is but if the SystemTap folks agree,
that is an easy discussion to start on LKML or with akpm.

gerrit

> Cheers,
>   Trond
> 
> > On Wed, 23 Aug 2006 17:17:52 +0200, Tony Reix wrote:
> > > Hello,
> > > 
> > > Can you answer the following questions asked by Trond Myklebust (NFSv4
> > > client) ?
> > > 
> > > Thanks,
> > > 
> > > Tony
> > > 
> > > 
> > > 
> > > I see several conditions that would need to be fulfilled before we even
> > > start to consider that:
> > > 
> > >  1) SystemTap would have to go into most (all?) distributions.
> >  
> > Getting there.  Why wait.  Just like all other things open-source,
> > get in on the development, be one of the first to use cool toys,
> > and YES, systemtap is heading there.  And, if you find a distro that
> > doesn't have it, ask here and suggest they include it.  This is OPEN
> > source, after all.  ;-)
> > 
> > >  2) There must be support for _all_ processor architectures: I'm not
> > > sure that they all have kprobes support for instance.
> > 
> > Oh, you know better than that!  All 38 processor architectures (okay,
> > I forgot the actual number)?  Again, when you find one that doesn't
> > work, let the arch maintainers know.  kprobes supports most of the
> > mainstream archs today, nothing fundamental standing in the way of
> > SystemTap supporting all of those.  When you find one that you care
> > about that doesn't work, let this list or the arch maintainer know.
> > 
> > >  3) The NFS code would have to stabilise considerably: if the code to be
> > > debugged keeps moving around, then maintaining a parallel set of
> > > SystemTap scripts would be a nightmare.
> > 
> > SystemTap can help stabilize the code!  It gives end users the ability
> > to help debug things without having your genius downloaded into their
> > Treo.  You'll get more intelligent bug reports and can ask for more
> > detail as generated by SystemTap.  Win-Win, I say!
> > 
> > gerrit
> 
>