| |||||||||||||
On DTrace envyOn DTrace envyPosted Aug 7, 2007 20:40 UTC (Tue) by dw (subscriber, #12017)Parent article: On DTrace envy
I can't help but think this is a knee jerk reaction to the (from my limited perspective) excellent post on Adam Leventhal's blog. There are certain things about that entry not covered here, such as the seemingly blatant plagiarism present in the "Red Hat Summit 2007" slides.
Can anyone mention a single good reason DTrace can't be lifted as-is, name kept and everything, into the Linux kernel? The Sun people seem to be pushing for this while the Linux people seem intriguingly silent on the issue.
Personally after reading that post and the various things it links to, I'd say DTrace is the better and more rigorously designed system.
(Log in to post comments)
On DTrace envy Posted Aug 7, 2007 20:49 UTC (Tue) by corbet (editor, #1) [Link] 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.
Drag-n-drop DTrace into Linux Kernel? Posted Aug 7, 2007 22:34 UTC (Tue) by pr1268 (subscriber, #24648) [Link] > 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! :-)
Drag-n-drop DTrace into Linux Kernel? Posted Aug 8, 2007 17:17 UTC (Wed) by madscientist (subscriber, #16861) [Link] A really interesting twist to this would be GPLv3.
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).
Drag-n-drop DTrace into Linux Kernel? Posted Aug 9, 2007 8:59 UTC (Thu) by nsoranzo (subscriber, #34668) [Link] > 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)
Obviously you mean ZFS, not XFS...
Nicola
Drag-n-drop DTrace into Linux Kernel? 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...
DTrace real port Posted Aug 9, 2007 10:25 UTC (Thu) by man_ls (subscriber, #15091) [Link] I'm surprised that nobody has asked the question, so it is probably an obvious stupidity. Anyway there it goes.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).
DTrace real port Posted Aug 9, 2007 15:47 UTC (Thu) by bcantrill (guest, #31087) [Link] Good luck with that.
DTrace real port Posted Aug 10, 2007 23:13 UTC (Fri) by man_ls (subscriber, #15091) [Link] 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 clone Posted Aug 10, 2007 14:48 UTC (Fri) by fuhchee (subscriber, #40059) [Link] 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 Posted Aug 10, 2007 23:09 UTC (Fri) by man_ls (subscriber, #15091) [Link] Merging upstream has to be done with SystemTap too. Is there any reason why it would be harder with a dtrace clone?And patent trouble has not stopped kernel developers before...
dtrace clone Posted Aug 11, 2007 20:53 UTC (Sat) by fuhchee (subscriber, #40059) [Link] > Merging upstream has to be done with SystemTap too.
Not as much as one might think. Systemtap relies only on existing
dtrace clone Posted Aug 11, 2007 22:09 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] please name anything in the kernel that has been put in if there is any doubt about the legality of it.
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)
dtrace clone Posted Aug 12, 2007 12:13 UTC (Sun) by man_ls (subscriber, #15091) [Link] 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.
On DTrace envy Posted Aug 7, 2007 21:36 UTC (Tue) by ahl (guest, #40497) [Link] Thank you for the kind words about my blog post. And, Jon, I think you did a terrific job with your analysis, and create a very balanced conversation.Regarding a DTrace port to Linux, that was the subject of my follow-on blog post which you can find here. In it, I put forth a hypothetical DTrace port which I believe conforms to all relevant licenses.
On DTrace envy Posted Aug 7, 2007 21:53 UTC (Tue) by tfheen (subscriber, #17598) [Link] Can anyone mention a single good reason DTrace can't be lifted as-is, name kept and everything, into the Linux kernel? The Sun people seem to be pushing for this while the Linux people seem intriguingly silent on the issue. DTrace is licenced under the CDDL, the Linux kernel is licenced under the GPLv2. Those two licences are incompatible, so any wholesale lifting of DTrace into Linux would give you a result which is (legally) undistributable. Given that Linux has so many contributors, it is for all practical purposes impossible to change the licence or add an exception allowing linking with the CDDL. Sun owns (afaik) the copyright to DTrace and could with a sufficient effort relicence DTrace under the GPLv2 which would allow lifting the code into Linux, barring any technical difficulties. Note that I am in no way saying that GPL is better or worse than the CDDL; they are just incompatible due to the GPL's requirement on "no further restrictions" and the CDDL's patent termination clauses. Also please note that I am in no way saying that Sun should relicence DTrace, only that if they want it to end up in the Linux kernel, as-is, relicencing is probably the easiest way to make that happen.
On DTrace envy Posted Aug 8, 2007 13:07 UTC (Wed) by paulj (subscriber, #341) [Link] DTrace is licenced under the CDDL, the Linux kernel is licenced under the GPLv2. Those two licences are incompatible, so any wholesale lifting of DTrace into Linux would give you a result which is (legally) undistributable. It's pretty simple. a) Follow AHL's recipe (see his blog, linked to several times in this article) That gets you GPLed reimplementation of certain DTrace bits for the linux kernel (perfectly redistributable) and CDDLed DTrace bits for the linux kernel (which a user is perfectly entitled to download and combine together with the GPLed bits - many Linux users already have long availed of this right to download and install completely proprietary Linux modules from their distributions repositories). For 100%-shiny-white redistribution, you need: b) Linux kernel developers to state they're fine with redistribution of CDDLed Linux kernel modules together with GPLed kernel and/or modules (remember, they're both free software licences). If the bulk of Linux devs of significance do so, then the problem is solved.
On DTrace envy Posted Aug 8, 2007 13:32 UTC (Wed) by paulj (subscriber, #341) [Link] "If the bulk of Linux devs of significance do so, then the problem is solved."
Hmm, I should re-state that, as in the above form it allows for possibly morally-bankrupt situations (e.g. some developers objecting, but who do not have resources to take action), which wasn't my intention. So:
"If no Linux kernel developers object, then there is no problem".
On DTrace envy Posted Aug 8, 2007 17:12 UTC (Wed) by madscientist (subscriber, #16861) [Link] > That gets you GPLed reimplementation of certain DTrace bits for the linux> kernel (perfectly redistributable)
While it is redistributable, I should point out that as described there's very little chance that those changes will ever be accepted into the mainline kernel. Linus et.al. have a long standing, and firm, position that no code will be accepted (even if it's perfectly legal GPL code) into the mainline kernel if its only purpose is to enable proprietary modules of one sort or another.
Of course, there's no reason why individual distributors like Red Hat, SuSE, Debian, etc. couldn't apply that patch themselves to their kernel packages, but this becomes a pain.
Of course, another option would be for the DTrace port to use existing, generic kernel facilities or, if none such exist, work on getting them added. This would be a lot more work, I expect.
On DTrace envy Posted Aug 8, 2007 17:28 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] In this case, that's not the purpose; DTrace is free software, not proprietary software, even though the license isn't compatible. Furthermore SystemTap could use the same hooks.
On DTrace envy Posted Aug 8, 2007 19:30 UTC (Wed) by ahl (guest, #40497) [Link] That's a very interesting point. I wonder if Linus et al. would object to hooks for an open source component, and, if they did, what the grounds for those objections would be.
On DTrace envy Posted Aug 9, 2007 11:47 UTC (Thu) by paulj (subscriber, #341) [Link] I don't want to sound too humbugish about attribution, but that was my point with "(remember, they're both free software licences)" from my point b) (get linux devs to agree CDDLed Dtrace modules are ok). Any points about potential odd-standards are implied in that (particularly as I had already referred to proprietary modules earlier in my post, highlighted in bold too to make it obvious..). :)
On DTrace envy Posted Aug 9, 2007 19:55 UTC (Thu) by bfields (subscriber, #19510) [Link] I wonder if Linus et al. would object to hooks for an open source component, and, if they did, what the grounds for those objections would be. That sort of thing has always met a lot of resistance. Currently any in-kernel API can be changed as long as you take care to fix up all the in-tree users. Obviously that makes certain kinds of changes much easier. And having in-tree users for API's makes those API's easier to understand and maintain.
On DTrace envy Posted Aug 8, 2007 21:30 UTC (Wed) by madscientist (subscriber, #16861) [Link] You're right, I misspoke. I wonder about ahl's point as well: is the Linux devs' position that they shouldn't create special hooks for code that is not GPL-compatible, and hence stands no chance of ever being integrated with the mainline kernel? Or is it only binary blobs they don't like? They really push hard the goal of getting everything promoted up to the mainline kernel.
Of course if it's the case that the in-kernel hooks can be made generic between SystemTap (et.al.) and DTrace, then it doesn't matter anyway.
On DTrace envy Posted Aug 29, 2007 20:06 UTC (Wed) by renox (subscriber, #23785) [Link] > Follow AHL's recipe (see his blog, linked to several times in this article)
Well AHL's "recipe" is the one followed by FreeBSD I think to use DTrace and they won't integrate DTrace in FreeBSDv7 because some of them have doubts about the legality of linking BSD code with CDDL headers.
The issue would be of course the same for the Linux kernel.
Is the legal issue real or not? Some say yes, some say no, I have really no clue..
Hopefully this legal mess will be cleared at some point, otherwise maybe Sun could relicense just the header under the BSD license to clear this mess once for all?
|
|||||||||||||