Submitted by This article goes into the motivation and architecture for DTrace — and describes some of the problems that remain to be solved in system observability. The article also includes a short case-study on using DTrace to find a real problem — a problem that was ultimately due to some seriously fugly code in a monitoring app.
DTrace in ACM Queue
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I have yet to use DTrace, but everything I have read really points to a seriously great tool!
I too have yet to try DTrace, however it looks like an excellent way to quickly discover obscure problems – we need more tools like this in open source!
I note with interest the attempt to port this over to FreeBSD, and wonder, is there any scope for porting DTrace to Linux? Looks like it’d be a huge amount of work, but I’m sure it’d pay dividends for those seeking to put it on the desktop.
Enjoyable & detailed article as well.
Edited 2006-02-03 13:36
I don’t think it’d be possible since it wouldrequire kernel level components and thus would be linked against the kernel ergo needing to be GPL licensed (which it is not) or applied seperately as a software patch.
I’m not a lawyer or anything but it might be possible to just reimplement the kernel layer of DTrace from scratch. I mean it probably just requires certain hooks into the running kernel which already exist for debugging. I’m making this sound trivial and it’s really not but legally I think it might be possible. If not there’s no reason we can’t come up with a work-alike for DTrace.
You also have to consider patent infringement as well
as copyright infringement.
I am not a lawyer (and this is not legal advice) but as far as CDDL is concerned, you can drop DTrace into anything. (Yes, Microsoft could drop DTrace into Windows or IBM could drop it into AIX — were either so inclined.) The issue around Linux is the GPL, not the CDDL: one would have to consult the FSF as to the interoperability of CDDL with the GPL, and Linus as to the Linux definition of the Program. Historically, the FSF has said that CDDL and GPL don’t mix — but Torvalds has been very murky on his definition of the Program. (In particular, the legal status of so-called “Tainted kernels” has never been tested.) If the definition were firmed up to limit the definition of the Program to those components explicitly licensed under the GPL (i.e. a file-based approach), then one could presumably drop DTrace into Linux without violating the GPL. I think if the Linux folks wanted DTrace enough — and certainly if Linus wanted it — they could find a way to legally do it. That said, I don’t think there’s much interest in DTrace among the influential Linux folks…
Sooner or later the Linux community is going to have to seriously consider why they want to port everything to Linux, when they can have the original. Well porting one cool technology may be an interesting idea, but Solaris 10 has a lot more than one cool thing.
Today you want DTrace, tomorrow you will want Zones, then your going to want more and more like SMF, RBAC, predictive self healing, fireengine, ZFS, brandz, ultra T1. These are just current technologies that Solaris offers, then there are things that Solaris has always brought to the table. Stability, Scalilibility, a stable API, and ABI.
If for some reason you still think there is a reason to port it all to Linux. Take a look at Linux’s track record. How long has it taken 2.6.x to get stable and enterprise ready? Solaris 10 was ready for the enterpise from the day it was shipped. Solaris/OpenSolaris is more stable in its beta form than Linux 2.6.x is today. How long do you think it will take to get all these technologies stable? Months? Years for each one. Mean while OpenSolaris/Solaris has continued on and is still far ahead and has many more cool technologies that Linux zellots will feverously try to port and stabilize.
In the end, maybe it would be best to use Solaris and not bother porting all this over. What does Linux offer again? Most companies only allow Red Hat in the door. So to have Linux you are paying $400 per CPU, instead of Solaris that is free. So it doesn’t have the same level of hardware support. $400 buys a lot of hardware, nvidia video card, and a new supported NIC barely makes a dent in the savings.
Edited 2006-02-04 06:42
I think there’s going to be a demand for an operating system that’s totally open-source for quite a while to come. As of right now, http://opensolaris.org/os/about/faq/binary_licensing_faq/#which-bin… states that parts of the OpenSolaris kernel are still covered by the binary license, so their source is not (yet) available. All of linux is open at this point, which makes it much more appealing to companies that won’t trust OSs that they can’t change.
Well it is nice you found the FAQ entry, but you should relize how little of the OS is distributed under that license. OpenSolaris is 15 million, in some 35,000 files. The closed binaries are less than 300 files. Also those 300 files are not the crown jewels, but drivers and a few program that Sun is still researching owner ship or trying to get permission to distribute.
ZFS, DTrace, brandz, zones, RBAC, fire engine, SMF, predictive self healing. Have all been released.
Those 300 files will be openned or rewritten from scratch in the future. So you can quibble about small details. Or you can embrace and extend.
Linux distros sometimes include closed source drivers, nvidia for one, the openned source versions don’t compare so most people used the closed source version.
If I was forced to find a fault, then it would be the code snippets which are bitmaps (can’t copy/paste). I know why this was done (“that’s not the code you need”), but then it would be nice to be able to emulate the error states, so for purely educative purposes, you might want to copy the code in some small program you write to try DTrace for size.
Congrats to Eugenia for finding this gem. More stuff like this!!
Edited 2006-02-03 14:28