Article on Sun's DTrace

[Daniel Ellard]

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