On DTrace envy
On DTrace envy
Posted Aug 7, 2007 20:49 UTC (Tue) by corbet (editor, #1)In reply to: On DTrace envy by dw
Parent article: On DTrace envy
This article has been in the works for a couple of weeks, and was not motivated by Adam's posting. And, yes, there's issues he raises there that I did not address - I was talking about the two technologies, not other bits of associated silliness.
As for putting DTrace into Linux - read the comments on Adam's posting. The GPL/CDDL incompatibility is something that Sun designed in; it cannot be wished away. If Sun were to dual-license DTrace under GPLv2, the situation would be different.
Posted Aug 7, 2007 22:34 UTC (Tue)
by pr1268 (guest, #24648)
[Link] (11 responses)
> If Sun were to dual-license DTrace under GPLv2, the situation would be different. Does there seem to be any indications that this could happen sometime in the future? I'm not trying to immediately discount SystemTap; but rather, I'm curious if Sun would/could be so persuaded. Thank you, Jon, for a wonderful article. Your research articles always seem to get the liveliest discussions! :-)
Posted Aug 8, 2007 17:17 UTC (Wed)
by madscientist (subscriber, #16861)
[Link] (1 responses)
There was some talk this past spring that Sun was looking at GPLv3 as a worthy successor for or alternative to CDDL. If Sun really does relicense OpenSolaris (and hence XFS and DTrace) under GPLv3 (or dual license it), I wonder if that's the "killer app" that would get the Linux kernel devs to re-examine the GPLv2 / GPLv3 issue. The buzz is that Linus and Co. are not as disdainful of the final GPLv3 draft as they were of some earlier versions, but that the effort involved with relicensing was widely seen as a waste of time with no real benefit.
Personally I doubt it would change anything on the Linux side; the people who would have to make this decision and do much of the work don't really seem to care much about DTrace (at least).
Posted Aug 9, 2007 8:59 UTC (Thu)
by nsoranzo (guest, #34668)
[Link]
Obviously you mean ZFS, not XFS...
Nicola
Posted Aug 8, 2007 20:22 UTC (Wed)
by khim (subscriber, #9252)
[Link]
Does there seem to be any indications that this could happen sometime in the future? Today there are no need for this: the parts of DTrace which can be easily lifted are already reimplemented in SystemTap, the stuff that remains is important, but tied to Solaris too tightly to be easily lifted...
Posted Aug 9, 2007 10:25 UTC (Thu)
by man_ls (guest, #15091)
[Link] (7 responses)
Why bother to port? Why not reimplement everything (including the kernel modules) and put it under GPLv2? Building a compatible implementation shouldn't require that much effort, even to the point where DTrace scripts can be shared (that is, those which are not too tightly coupled to Solaris internals).
Posted Aug 9, 2007 15:47 UTC (Thu)
by bcantrill (guest, #31087)
[Link] (1 responses)
Posted Aug 10, 2007 23:13 UTC (Fri)
by man_ls (guest, #15091)
[Link]
Posted Aug 10, 2007 14:48 UTC (Fri)
by fuhchee (guest, #40059)
[Link] (4 responses)
Posted Aug 10, 2007 23:09 UTC (Fri)
by man_ls (guest, #15091)
[Link] (3 responses)
And patent trouble has not stopped kernel developers before...
Posted Aug 11, 2007 20:53 UTC (Sat)
by fuhchee (guest, #40059)
[Link]
Not as much as one might think. Systemtap relies only on existing
Posted Aug 11, 2007 22:09 UTC (Sat)
by dlang (guest, #313)
[Link] (1 responses)
the license and patent status of dtrace is very much a reason for it not being considered (in fact, due to these issues most of the kernel developers don't even look at it to avoid any accusations of them being tainted)
Posted Aug 12, 2007 12:13 UTC (Sun)
by man_ls (guest, #15091)
[Link]
Drag-n-drop DTrace into Linux Kernel?
A really interesting twist to this would be GPLv3.Drag-n-drop DTrace into Linux Kernel?
> There was some talk this past spring that Sun was looking at GPLv3 as a worthy successor for or alternative to CDDL. If Sun really does relicense OpenSolaris (and hence XFS and DTrace) under GPLv3 (or dual license it)Drag-n-drop DTrace into Linux Kernel?
Drag-n-drop DTrace into Linux Kernel?
I'm surprised that nobody has asked the question, so it is probably an obvious stupidity. Anyway there it goes.
DTrace real port
Good luck with that.DTrace real port
Is there any specific problem you see with this approach? Not that it is an easy task, but after all there is a working implementation with source code to study. It would probably be easier than working around the limitations you people have exposed in SystemTap, wouldn't it?
DTrace real port
There are several obstacles. Rewriting the code is a relatively small part. Merging upstream is huge and controversial. There may also be legal (patent) barriers.dtrace clone
Merging upstream has to be done with SystemTap too. Is there any reason why it would be harder with a dtrace clone?
dtrace clone
> Merging upstream has to be done with SystemTap too.dtrace clone
externalized kernel interfaces and hooks - no changes just on our
account. That's not to say it wouldn't be nice to get some extra
interfaces/hooks, or to offload some version drift maintenance to other
folks. It means that we can work toward their development and upstream
inclusion gradually, without blocking the rest of the work.
please name anything in the kernel that has been put in if there is any doubt about the legality of it.dtrace clone
As you probably know, any non-trivial piece of code probably infringes on a lot of patents. That hasn't stopped kernel developers from improving the kernel, and rightly so. Maybe the situation with specific patents is different.
dtrace clone