Re: [9fans] dtrace for plan 9

[Roman Shaposhnik <roman@shaposhnik.org>]

On Mon, Nov 9, 2009 at 7:08 PM, Devon H. O'Dell <devon.odell@gmail.com> wrote:
> 2009/11/9 erik quanstrom <quanstro@coraid.com>:
> That said, my knowledge of DTrace internals greatly surpasses my knowledge of how to
> actually use it, so I'll let Roman help out on that front :)

Which means -- we can nicely compliment each other ;-)

>> before we go all crazy, has anyone else tried ron's
>> great tracing?
>
> It's good, I read the paper and played around with it while I was
> doing some 9vx work. But it's not really the same. Devtrace implements
> a subset of DTrace's functionality.

Well said. I played with it in a very limited context and for what it
was built -- I felt
it was a nice tool. As a matter of fact, at the same time I suggested
to Ron that
a more DTrace'ish extensions of his work could be interesting. More on
that later.

> DTrace does more than syscalls, and a lot of the talk on this thread
> seems to be focused around that, so please let me clarify a bit.

To me, the greatest value of DTrace comes from the fact that it is a
*unified* tracing framework that lets you trace events throughout multiple
layers of software. You can start tracing at the level of hardware interrupt,
pick the event up in Apache, continue into Tomcat and all the way into
middleware.

Yes, I know, on a cleanly designed system -- none of this nonsense would
be needed anyway, but when it is "turtles all the way down" DTrace can let
you see how stuff percolates quite neatly. All the way up to...

> It's also fairly easy to do this. I was at a party with the Sun guys
> at OSCon in 2005. Wez Furlong wrote a DTrace provider for PHP in about
> 30 minutes with Bryan Cantrill, who then rather excitedly ran to me
> explaining how I needed to come look (this is a gross understatement
> for brevity). It was pretty cool, and the code needed for the DTrace
> hooking was smaller than the PHP module skeleton code.

...your own application. Being able to expose the states of your app in
an efficient and unified manner is quite helpful.

> While extending it may be done relatively easy, it is quite big. When
> I was working on porting it to FreeBSD (before jb@ essentially usurped
> the project, anyway), I spent 3 weeks getting CTF and the base DTrace
> provider ported over. Granted, I was much less experienced than now,
> but it is a significant amount of work to reproduce all the
> functionality. I'd estimate a finished version to be about the size of
> the Plan 9 kernel.

Right. I guess the trick is to see how close are we to a point of diminishing
returns. Ron's stuff covers kernel pretty neatly and for everything else -- its
easy enough to spill the guts via 9P.

Thanks,
Roman.