CRiSP Weblog

Somebody pointed me at the lwn.net website regarding the 2008 Linux summit and tracing toolkits. We seem to get a mention, and thought I ought to update the blog, as I have been lax over the past couple of months.

So, what is happening to dtrace? Its waiting for me to dive back in, having forgotten how it works....

Over the last couple of months I have been busy on other projects which had gathered dust.

proc

Firstly, 'proc' - a colored top, which does what I want, which 'top' doesnt. You can grab a binary from my downloads/tools section. I am still finding new stuff to add to it. Its ok - it tells me what I want to know about what a system is doing, just like top. It started as a project a long time ago, back on SunOS 4.x, and has been reworked for Linux. (Note, it doesnt play well with some terminal emulators, and I must document it and/or package up the source, but I am lazy !)....

fcterm

fcterm is my color terminal emulator. Written a long time ago as I was learning X windows programming, and the precursor to CRiSP - the editor. Recently I decided I wanted infinite scrollback and searching, having read about the 'Terminator' app on Elliotts Blog (http://elliotth.blogspot.com/). Written in java and its nice, but I wanted to go one better.

fcterm is faster than any other terminal emulator I have measured and now has near infinite scrollback (I will explain about this one day). Its taken a while to iron out the kinks, it works perfectly with 'cr' the editor, and is very useful.

Ok - back to the plot....

dtrace

I put a lot of effort into kernel and user space stack tracing parts of dtrace. It works, but Linux doesnt. Or rather, the way distros are compiled (gcc -fomit-frame-pointer) means you cannot get a good stack trace inside or outside the kernel. What you get depends on what a distro decided to do when they compiled code. Even on 64-bit, they use this flag when they dont need to. Sun doesnt do this, and so dtrace works beautifully. This put me off - acceptance of dtrace will be limited whilst it looks like *it* doesnt work, when its what distro makers do which dilutes the impact of dtrace.

lwn.net article on dtrace

Theres a good article on dtrace and SystemTap and the Linux traceing toolkit here: http://lwn.net/Articles/298685. DTrace for linux gets a mention.

(Aside: I was asked to contribute an article to lwn.net, but I just got too busy with other stuff to fit it in, and my grammar isn't too hot, but c'est la vie, maybe I will finish and/or distribute the partly finished detailed documents I have assembled).

The Big Deal

Heres the deal on DTrace for linux -- look at it, try it out. It may not work, but then its free, it costs nothing, and *you* are the one, yes *YOU* the reader, who can make it work. Me, I'm just a coding-donkey trying to hit the right keys on the keyboard, but whether DTrace ever lands in your distro is up to you.

The GPL vs CDDL debate is great for a bar/pub discussion, but everytime DTrace is mentioned, this gets dragged up.

The CPU in my machine is Intel (as I write). That CPU costs me money. Its full of patents, licenses and other commerical stuff. The CPU is not compiled into the kernel - its a blob of silicon. Add Linux to the CPU and hey presto ! They do something useful.

This is DTrace for Linux: no kernel source is needed (except compilation headers). No patches are made to the kernel source. Its a drop in driver. Once the driver is loaded, you can run dtrace. I am not even asking Linus or any other kernel maintainer to 'please add dtrace' to the kernel. I dont care - - thats just me ! Maybe, one day, when I have documented 'proc', and 'fcterm', and decided I want to enjoy the politics of kernel maintenance, I might ask.

But DTrace for Linux is just a bunch of software - you can read, modify, compile and use. Its 'free' as in 'beer'. I dont claim any rights over it, despite a lot of effort to get this far. If you are reading this far, you must be interested.

DTrace isnt for everybody - its technical, it requires understanding, but the technical audience can translate this into availability. Once dtrace is available, the dtrace scripts come into power.

Guess I am just ranting and finding an excuse not to add the next feature to "proc".

DTrace is on my agenda in the next few weeks to carry on from where I left off. I have not been brace enough to keep it loaded on a real kernel (I have only run it in VMware sacrificial lamb kernels, so I need to eat my own dog food).

Chat soon!