|dtrace progress 20080925 - lwn.net||Thursday, 25 September 2008|
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.
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 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....
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).
Posted at 20:58:45 by Paul Fox | Permalink