In a nutshell, here is what DTrace is about:
- It has no impact on the system when it is not used. So you can
leave it in all the time, instead of having a debug kernel and
a production kernel.
[I don't know how they achieve the "no impact" but they claim
that they really mean "no", not just "negligible".]
- It allows you to analyze pretty much any aspect of the kernel that
you like, and it has hooks into userland as well. So if you
have strange behaviors happening due to a badly-written
process, you can track down what that process is doing.
They demonstrate some nice examples of this.
- The D language is what you use to specify how the trace info is
filtered/processed/presented to you.
D is not a complete programming language. It is highly
constrained (i.e. no loops, no recursion, etc) in order to
make sure that every path through a D program completes in
finite time (otherwise, a bug in your D program might
effectively hang the kernel, which is a no-no).
So, you could think of it as "a million debugging printf's magically
inserted into the kernel for you" along with a tool to analyze the
output, but it's really much more sophisticated than that.
It looks very nice. I wish I'd had it during my forays into the
FreeBSD kernel. Is it hopelessly solaris-specific? Well, I was at
the presentation that Bryan Cantrill gave at USENIX, where he was
asked about the possibility of porting DTrace to linux. His response
was something like "well, we're really trying to encourage people to
use the *best* possible operating system, so no." (Of course, one
might argue that this means that a FreeBSD port is imminent, but I
don't think that's what he meant.)
-Dan
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
