While browsing LWN archives I found a thoughtful article introducing DTrace, written by filesystems developer Valerie Henson -
See also her book reviews in the Kernel Hackers Bookshelf series, such as -
While we’re on the topic of filesystems, I’d recommend Practical File System Design with the Be File System [pdf download ] by Dominic Giampaolo. As well as being totally free to download, this book is a delight to read with practical examples explaining all the ideas. Id read it cover to cover before diving into the internals of any of the current fs incarnations – EXT3/4, XFS, ZFS or the in-progress btrfs.
Back to DTrace – I believe Linux _needs_ DTrace. Purely on stylistic grounds, in the same way that any respectable unix needs ls, grep or strace.
DTrace has great style, in the best un*x tradition. If its unlikely that a _port_ of DTrace will get into the linux kernel due to legal reasons, then the only option is to embrace the ideas of DTrace, and implement something comparable [perhaps D language compatible]. I’ve read Bryan Cantrils heartfelt exhortations that a DTrace clone would either be a straight port or a feature-poor dead duck in the water [my paraphrase]… but you could say that about any great piece of unix code… yet the successful ones embrace the beauty, utility and ethos of the original and faithfully live up to it. I hope when this happens the authors of the original DTrace will give the linux clone their blessing, as a homage to their effort.
enjoy,
gord.
2 comments
Comments feed for this article
January 18, 2009 at 11:17 pm
Bryan Cantrill
Interesting commentary, and we certainly appreciate the kind words about DTrace. (We have great reverence for the Unix pantheon, and — like classical revivalists — have always sought to develop software in its mold.) As for Linux developing a clone of DTrace: it’s highly unlikely in my opinion that anyone would engage in such an effort when a port in so much easier. Remember: it took three highly skilled kernel engineers three years of complete focus to develop DTrace. For a Linux equivalent, you would need the likes of Ingo Molnar to dedicate themselves to this — and I don’t see an Ingo-class engineer picking this up simply because it is out of step with the values of Linux: debugging is not held in high regard by Linux kernel developers (an attitude which emanates from Linus himself), and I have a hard time seeing the top Linux developers dedicating themselves to a task held in such low esteem by their peers. But even assuming that the right engineers could be assembled and motivated, who is going to pay for this effort for Linux? Not Red Hat, apparently, as they have already spent more time and energy on a knock-off that reflects little understanding of even the problem that DTrace solves, let alone DTrace itself. Who does that leave? IBM? Intel? Oracle? I don’t see any of these companies picking up the tab for this, especially as they individually don’t have that much to gain from it. Even assuming that the Sugar Daddy could be found for this, why would they want to pay to develop a clone when they could port it for so much less? To sum: our “blessing” is the least of the problems for a DTrace implementation on Linux — cultural and economic obstacles are much more pressing hurdles…
January 19, 2009 at 12:32 am
quantblog
Thanks for the comments Bryan – your probably right, tracing in Linux will most likely have to evolve to the point where it has almost all of the same ideas that were worked out in DTrace.
Some random thoughts -
I wonder if ‘not-invented-here’ syndrome prevents a direct port going in [even if everyone did agree the licenses were compatible]. But not-invented-here is often a healthy attitude to have as a developer, or we wouldn’t have any great software in the first place.
Maybe a port would look like a rewrite anyway, just because its sitting in quite a different kernel.
I think it actually would be in say IBMs business interests to hire 3 guys to work on DTrace functionality for Linux.. You here that IBM – ’show me the money’
Things as they are, I guess well see linux have more and more features of DTrace incrementally… and gradually catch up with everyone else over the next few years. ouch.
Maybe a first step is to have a kprobe which can put in trace breakpoints dynamically after module init… Now, is that a feature I want to work on out of my own pocket, or would I like to make something sexy and new? tough Qn, hmmm…
If linux community doesn’t want a full byte-code interpreter in the kernel.. what about something like the packet filter approach? It seems a similar problem – you want to have a general query to filter matching events, have those programmable at runtime and do it just incredibly fast.
On the upside, theres always the possibility someone will come along with another really good idea that makes tracing even better.. either by accident, or because they’ve had to think through for themselves all the same problems the DTrace team encountered – thats not a bad thing [I suspect this happens in nature with evolution of species, the advance might 'pay' for the gross inefficiency of copying something that already works excellently.]
Btw, the 3 years of effort you guys put in really does show. I know most projects I was happy with took order of magnitude more work to get done than anyone thought.. theres the first 90%, then the last 90%, then the last 90%… :]
cheers mate. and happy inauguration week – Can we copy DTrace {badly|well} – ‘yes we can’.