This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, 23 Aug 2006 12:10:55 EDT, Trond Myklebust wrote:[...]
On Wed, 2006-08-23 at 08:43 -0700, Gerrit Huizenga wrote:
:)Ah, but you appear to be missing an important point. Tony was asking if
Comments interspersed...
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.
Debugging tools are user space utilities so i am not sure, what you mean by needs to be in Linus's tree. All the kernel pieces like kprobes, relay fs etc. are already in the mainline. If you are talking about maintaining the tools just like all the tools in the user space we have committed set of people maintaining them and we will continue to do going forward as well.
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
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.
I can't agree more here.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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |