This originally was going to be a post-mortem on dtrace.conf, but so much time has passed, that I doubt it qualifies anymore. Back in March, we held the first ever DTrace (un)conference, and I hope I speak for all involved when I declare it a terrific success. And our t-shirts (logo pictured) were, frankly, bomb. Here are some fairly random impressions from the day:
Notes on the demographics at dtrace.conf: Macs were the most prevalent laptops by quite a wide margin, and a ton of demos were done under VMware for the Mac. There were a handful of dvorak users who far outnumbered the Esperanto speakers (there were none) despite apparently similarly rationales. There were, by a wide margin, more live demonstrations that I’d seen during a day of technical talks; there were probably fewer individual slides than demos — exactly what we had in mind.
My favorite session brought the authors of the three DTrace ports to the front of the room to talk about porting, and answer questions (mostly from the DTrace team). I was excited that they agreed to work together on a wiki and on a DTrace porting project. Both would be great for new ports and for building a repository that could integrate all the ports into a single repository. I just have to see if I can get them to follow through now several weeks removed from the DTrace love-in…
Also particularly interesting were a demonstration of a DTrace-enabled Adobe Air prototype and the very clever mechanism behind the Java group’s plan for native Java static probes (JSDT). Essentially, they’re using the same technique as normal USDT, but dynamically generating the tracing description structures and sending them down to the kernel (slick).
The most interesting discussion resulted from Keith’s presentation of vprobes — a DTrace… um… inspired facility in VMware. While it is necessary to place a unified tracing mechanism at the lowest level of software abstraction (in DTrace’s case, the kernel), it may also make sense to embed collaborating tracing frameworks at other levels of the stack. For example, the JVM could include a micro-DTrace which communicated with DTrace in the kernel as needed. This would both improve enabled performance (not a primary focus of DTrace), and allow for better domain-specific instrumentation and expression. I’ll be interested to see how vprobes executes on this idea.
Requests from the DTrace community:
- more providers ala the recent nfs and proposed ip providers
- consistency between providers (kudos to those sending their providers to the DTrace discussion list for review)
- better compatibility with the ports — several people observed that while they love the port to Leopard, Apple’s spurious exclusion of the -G option created tricky conflicts
Ben was kind enough to video the entire day. We should have the footage publicly available in about a week. Thanks to all who participated; several recent projects have already gotten me excited for dtrace.conf(09).
5 Responses
Yeah, best conference tees ever.
"The most interesting discussion resulted from Keith’s presentation of vprobes — a DTrace… um… inspired facility in VMware."
Glad you enjoyed the talk! And to be clear, there’s no elliptical "um" about it: DTrace did, indeed, inspire VProbes, and without DTrace’s precedent, VProbes would probably be very different. I hope I didn’t come off otherwise.
On a more important note: I forgot my t-shirt at the conference :(. Whose car might I wash to get one? Men’s small or medium would do …
@Keith I was trying to suggest another descriptor, but stopped short. As to your t-shirt, I’ve got your back, but it might be a bit roomy — only larges were left. Let me know where you want it sent.
I am currently in Sunnyvale, CA doing endless rounds of interviews.
Next week I’ll be in Ottawa for the http://bsdcan.org/ conference where I’ll be presenting a paper on the DTrace port to FreeBSD. The conference includes other flavours of BSD, so hopefully the others will show some interest.
I’ve arranged to meet with Colin Burgess to discuss the porting project and how we might proceed with that.
I forgot to mention that there is also a Google Summer of Code project approved to port the DTrace Toolkit to FreeBSD.
The clean-room implementation of CTF parsing missed the cut-off though, unfortunately.