LWN: Comments on "Oracle works on Dtrace for Linux (The H)"

But

oak — Tue, 25 Oct 2011 21:36:12 +0000

Regarding LTTng, I think this is the most significant thing in the comparison:
"provides analysis tools to navigate in large multi-GB traces"

With LTTng you can profile "everything" happening in the system with pretty low overhead, i.e. when you still aren't sure what exactly is causing the issues. The others are intended for more targeted tracing where you often write your own script to trace things.

On other platforms than x86, one Systemtap issue is that it relies completely on kprobes instruction emulation to be correct. There were a lot of issues in that e.g. on ARM which have been only recently corrected.

But

khc — Mon, 10 Oct 2011 18:18:53 +0000

Work? I tried to evaluate it a while ago (FC15 beta, so it wasn't THAT long ago) but I hit kernel panic whenever I try to put load on it (a heavily multi-threaded program). The redhat guys I chatted with on IRC were really helpful and fixed some issues (but not all), but I didn't have time to pursuit further.

A coworker ported our code to Solaris and dtrace hasn't had a problem with it yet. The situation is not ideal as we actually ship on Linux, but we only use tracing internally now so it's not too big of a deal.

But

cmccabe — Mon, 10 Oct 2011 04:20:22 +0000

> Just what does dtrace do that SystemTap can't (yet) do?

There's a comparison of the 4 horses in this race at:
http://sourceware.org/systemtap/wiki/SystemtapDtraceCompa...

It's worth noting that perf isn't really comparable to the other 3 systems because it has a lot more peformance impact. It's really intended more for profiling than for running in production.

Also, LTT-ng and DTrace are not in mainline.

But

vonbrand — Mon, 10 Oct 2011 01:43:32 +0000

Presumably the variables and functions to monitor are sufficiently different between Solaris and Linux that the supposed advantage of dtrace just doesn't exist.

But

tialaramex — Sat, 08 Oct 2011 23:53:00 +0000

Thanks for that information. It seems as though this would make Oracle's attempt to port DTrace to Linux rather tricky, unless there is now equivalent expertise among a new generation of hackers at Oracle.

But

rahulsundaram — Sat, 08 Oct 2011 19:59:26 +0000

Yes. Utrace/uprobes need to be merged. It doesn't matter much where the user space tool lives.

But

fuhchee — Sat, 08 Oct 2011 19:30:26 +0000

"till it requires no kernel patches"

I assume you're referring to utrace/uprobes. Yes, only probing general user-space requires these, and we can hardly wait until these are mainstream.

"and everything is in the mainline kernel"

If you're repeating the previous point, ok.
If you're suggesting that a tool must be distributed within the kernel tree in order to be useful, then considerable experience says otherwise.

But

rahulsundaram — Sat, 08 Oct 2011 19:02:46 +0000

Adoption is very limited at this point and wont grow till it requires no kernel patches and everything is in the mainline kernel. That is a huge problem.

But

bcantrill — Fri, 07 Oct 2011 20:36:15 +0000

A point of clarification: the DTrace experts do not, in fact, work for Oracle; all three of the original team have left, as has Brendan Gregg (author of both the DTraceToolkit and the recent book on DTrace). A minor point, perhaps, but a significant one for those of us who have parted ways with the company -- especially as DTrace has continued to be developed under different ownership.

Oracle works on Dtrace for Linux (The H)

liljencrantz — Fri, 07 Oct 2011 14:13:57 +0000

Oracle is completely indifferent to nurturing a healthy Eco-system of open source projects unrelated to their core strategy. Their behavior towards OpenOffice, Hudson and a long list of other projects is just that: indifference.

The Linux kernel they care about. They want it to flourish, because they _know_ they can't compete with Microsoft alone; if _they_can't be the OS monopolist, the second best option is that nobody is the OS monopolist. That's why they're being good citizens and fixing loads of kernel bugs and working on shiny new features like btrfs within the kernel community. No periodical code drops like some other companies I could mention.

That's why my best guess would be that if something comes of this, the entire kernel space solution will be GPLv2, possibly even the user space component.

Oracle works on Dtrace for Linux (The H)

simlo — Fri, 07 Oct 2011 13:00:23 +0000

This is my interpretation of GPLv2:

Linux with DTrace kernel modules will be one program and must as a whole be under GPLv2. Linux+DTrace is a derived work of Linux.

You can distribute Linux with some DTrace stubs as GPLv2. Then DTrace under another license can be distributed as that is clearly not a derived work of Linux - the same way NVidia distributes their grapics driver.

But

fuhchee — Fri, 07 Oct 2011 12:01:14 +0000

Systemtap has not limited itself to dtrace capabilities as an end goal. It already exceeds it in some interesting ways, and we plan to keep that going.

But

tialaramex — Fri, 07 Oct 2011 10:02:18 +0000

Very importantly, it has traction, particularly with Oracle's big audience of administrators and system programmers from a proprietary Unix background. Even if SystemTap does absolutely everything DTrace does, you know DTrace already.

This isn't a _huge_ audience, but it is one that's comfortable paying Oracle money. Making sure these people have a reason to ask specifically for Oracle's Linux, not Red Hat, will pay for itself. Previously DTrace was a reason for Solaris administrators to resist going Linux at all, but Oracle doesn't care about that, so it wants DTrace on Linux.

The license doesn't actually matter so much. If you know you want DTrace, that's a reason to choose Oracle, because the DTrace experts work for Oracle.

But

robert_s — Fri, 07 Oct 2011 08:50:20 +0000

Just what does dtrace do that SystemTap can't (yet) do?

Oracle works on Dtrace for Linux (The H)

cmccabe — Thu, 06 Oct 2011 23:25:11 +0000

> 1. Take advantage of lack of patent protections in the Linux
> kernel and keep the patent licensing separate from the
> copyright licensing.

GPLv2 does provide an implicit patent license:

http://en.swpat.org/wiki/GPLv2_and_patents

> 2. Take advantage of the fact that copyright controls can only be extended
> to derived works. If they figure out a way to use dtrace in the Linux
> kernel in a way that leaves it relatively unmodified then there is no
> effective way that it can be claimed as derived works...

I think this is exactly what they'll do. Set up a GPLv2 shim layer, and leave the core code as CDDL.

Of course, it will never be upstreamed, and will need constant maintenance to stay in sync with the rest of the kernel. However, Oracle has the money and the engineers to keep it going.

Hopefully this will motivate people to finally improve and unify the upstream Linux tracing situation...

Oracle works on Dtrace for Linux (The H)

sciurus — Thu, 06 Oct 2011 22:40:49 +0000

From the blog post: "some small kernel components and header files will be dual-licensed while the bulk of DTrace the kernel modules, libraries, and commands will use the CDDL"

It sounds like they're trying to release just enough under the GPL to get away with distribution.

Oracle works on Dtrace for Linux (The H)

Wol — Thu, 06 Oct 2011 22:28:42 +0000

No. Sun appears to have owned dtrace, and if they do then Oracle now own it.

The interesting thing, as I see it, is the blog implies that dtrace is going to be released as CDDL. Seeing as that's incompatible with GPL, it means that Oracle will either be unable to distribute, or will be forced to distribute the source on the same medium as the binary (due to a quirk/bug in GPLv2, they will NOT REPEAT NOT be able to distribute compiled kernels electronically eg on the web).

Or force all customers who want to use it to compile their own kernels.

We'll see.

Cheers,
Wol

Oracle works on Dtrace for Linux (The H)

dlang — Thu, 06 Oct 2011 21:29:19 +0000

I didn't mean to imply that they would have a _legal_ basis for their 'competitive advantage', merely that I would not be surprised if they tried to maintain one.

Oracle works on Dtrace for Linux (The H)

dlang — Thu, 06 Oct 2011 21:26:15 +0000

Oracle's track record since they acquired Sun has not been good. They have killed or alienated many different communities. In fact I can't think of any actions they have taken since that point that would be considered positive (aside from the quiet continuation of pre-existing initiatives)

Oracle works on Dtrace for Linux (The H)

drag — Thu, 06 Oct 2011 21:14:20 +0000

The only shenanigans they could play that I could see would be to:

1. Take advantage of lack of patent protections in the Linux kernel and keep the patent licensing separate from the copyright licensing.

2. Take advantage of the fact that copyright controls can only be extended to derived works. If they figure out a way to use dtrace in the Linux kernel in a way that leaves it relatively unmodified then there is no effective way that it can be claimed as derived works and thus would be legal to keep licensed under the CDDL. It's something that was written for a different OS entirely and ported to several others, so only the linux-specific parts of dtrace would have to be licensed under the GPLv2.

This is similar to how Nvidia takes their Windows driver and shoves it into the Linux kernel with their 'GPL shim'.

---------

But I don't know why people are so eager to assume that Oracle will pull crap like this. They have released many software patches and such as GPLv2. They are responsible for Btrfs and a lot of other work that was done to enhance the Linux kernel. As far as I can tell Oracle has shown no other signs or desire that they wish to make the Linux they ship be 'proprietary' in any substantial way.

I think most of this line of thinking stems from the common belief that Oracle sees Solaris as a potential competitor to Linux. I don't think that is Oracle's desire at all... I don't think they give a flying-f for Solaris or Sun hardware besides being a legacy OS and system that gets relatively minor updates time to time to keep the big players with solaris-specific applications happily puking huge gobs money at their feet. They Oracle may talk up a good game about Solaris, but I think that is just because big enterprise people tend to be nervous ninnies and need the reassurance that Oracle isn't planning to pull the rug out from underneath them.

Java was their primary concern as far as Sun acquisition goes. I think that Solaris was almost incidental. I don't think they care a whole lot one way or another as long as their is at least one very popular platform available to run their application stack that isn't owned by Microsoft.

We will see if what I say is true based on how Oracle decides to license it. If I am right then they will probably have the Linux-kernel portions be dual licensed and the userland parts may or may not stay under a CDDL-only... which is just fine because CDDL is a friendly free-software license.

Oracle works on Dtrace for Linux (The H)

fw — Thu, 06 Oct 2011 20:59:24 +0000

We don't really know if they have the rights for a Linux port. Sometimes, big company make odd mistakes, like Ebay buying Skype the company, but not all Skype-related technology.

Oracle works on Dtrace for Linux (The H)

dlang — Thu, 06 Oct 2011 20:18:03 +0000

it will be very interesting to see what they end up doing. I would not be surprised to see them try something wrong with the licensing here trying to maintain some 'advantage' and then get sued over it.

although, all they really need to do to keep their 'advantage' is to do such a horrible hack job with the 'port' that the result is not acceptable upstream.

Oracle works on Dtrace for Linux (The H)

JoeBuck — Thu, 06 Oct 2011 20:11:54 +0000

Oracle owns the code, so they are free to relicense their port however they want. On the other hand, they are fiercely competitive and will probably try to find some way of maintaining an advantage over the competition (e.g. Red Hat).