A uprobes addendum
| From: | Linus Torvalds <torvalds-AT-linux-foundation.org> | |
| To: | "Frank Ch. Eigler" <fche-AT-redhat.com> | |
| Subject: | Re: linux-next: add utrace tree | |
| Date: | Thu, 21 Jan 2010 17:32:47 -0800 (PST) | |
| Message-ID: | <alpine.LFD.2.00.1001211729080.13231@localhost.localdomain> | |
| Cc: | Andrew Morton <akpm-AT-linux-foundation.org>, Stephen Rothwell <sfr-AT-canb.auug.org.au>, Ingo Molnar <mingo-AT-elte.hu>, Ananth N Mavinakayanahalli <ananth-AT-in.ibm.com>, Peter Zijlstra <a.p.zijlstra-AT-chello.nl>, Peter Zijlstra <peterz-AT-infradead.org>, Fr??d??ric Weisbecker <fweisbec-AT-gmail.com>, LKML <linux-kernel-AT-vger.kernel.org>, Steven Rostedt <rostedt-AT-goodmis.org>, Arnaldo Carvalho de Melo <acme-AT-redhat.com>, linux-next-AT-vger.kernel.org, "H. Peter Anvin" <hpa-AT-zytor.com>, utrace-devel-AT-redhat.com, Thomas Gleixner <tglx-AT-linutronix.de> | |
| Archive‑link: | Article |
On Thu, 21 Jan 2010, Frank Ch. Eigler wrote: > > To the extent the discussion is colored by the new features enabled > from this refactoring, well, there is Oleg's list which may or may not > have mentioned enabling systemtap's user-space probing. Let's face it, system tap isn't going to be merged, so why even bring it up? Every kernel developer I have _ever_ seen agrees that all the new tracing is a million times superior. I'm sure there are system tap people who disagree, but quite frankly, I don't see it being merged considering how little the system tap people ever did for the kernel. So if things like system tap and "security models that go behind the kernel by tying into utrace" are the reasons for utrace, color me utterly uninterested. In fact, color me actively hostile. I think that's the worst possible situation that we'd ever be in as kernel people (namely exactly the "do things in kernel space by hiding behind utrace without having kernel people involved") Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Posted Jan 22, 2010 2:24 UTC (Fri)
by ananth (guest, #12051)
[Link]
Uprobes can and will be implemented without the utrace dependency -- there is sufficient interest in having some form of userspace tracing in Linux.
Posted Jan 22, 2010 12:32 UTC (Fri)
by stumbles (guest, #8796)
[Link]
Posted Jan 23, 2010 14:30 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (24 responses)
I'm utterly confused by all the tracing stuff: utrace, ptrace, SystemTap,
WTF are they?
Posted Jan 23, 2010 17:48 UTC (Sat)
by adobriyan (subscriber, #30858)
[Link] (2 responses)
Never.
Posted Jan 24, 2010 18:27 UTC (Sun)
by ahl (guest, #40497)
[Link] (1 responses)
> Never.
Or immediately: http://www.crisp.demon.co.uk/
Definitely sometime in that range...
Posted Jan 25, 2010 9:18 UTC (Mon)
by adobriyan (subscriber, #30858)
[Link]
Posted Jan 25, 2010 3:16 UTC (Mon)
by njs (subscriber, #40338)
[Link] (20 responses)
kprobes/utrace/dynamic probes are names for difference parts of the various tracing systems people are writing; if you just want to know when we'll get DTrace then you don't care about their details. (DTrace has a bunch of comparable internal pieces too, of course.)
SystemTap is an end-user product that attempts to provide approximately the same capabilities as DTrace.
DTrace doesn't exist on Linux because it fit Sun's strategic goals to keep it as a differentiator between Linux and Solaris, and they licensed it accordingly. Oracle has different strategic interests, so it'll be interesting to see if they have a different take on this.
Posted Jan 25, 2010 12:01 UTC (Mon)
by trasz (guest, #45786)
[Link] (13 responses)
Also, note that the whole problem with compatibility is caused by GPL, not CDDL. Sun had two choices - either release the code under GPL, making it pretty much impossible to use by everyone except Linux, or release it under more sane copyleft license that doesn't create additional hurdles for end users. They chose the latter, and I think it was a good choice - even if it was GPL-ed, Linux developers would reject it due to NIH (see e.g. the rubbish about "layering violations").
Posted Jan 25, 2010 12:26 UTC (Mon)
by patrick_g (subscriber, #44470)
[Link]
Posted Jan 25, 2010 13:43 UTC (Mon)
by ringerc (subscriber, #3071)
[Link] (11 responses)
That's not true of DTrace, which must be deeply integrated throughout the kernel. Doing it as a binary module would require vast numbers of currently-unexported symbols to be exported (creating bloat) and would require many GPL_ONLY symbols to be exported w/o that flag, something that often can't be done without the agreement of the authors of that part of the code.
So: As things stand, licensing issues prevent integration of DTrace into the Linux kernel.
As for the compat issue being caused by the GPL, not the CDDL: Yes, that's true to an extent, in that the GPL is a painful license to use other code with. However, it's entirely reasonable and possible to dual-license code (including CDDL+GPL, see Glassfish etc) and Sun could've chosen a GPL+CDDL license that would've permitted all current uses plus integration with GPL code. They chose not to because, for commercial strategic reasons, they wanted ZFS and DTrace to be differentiators between Solaris and Linux. Fair enough, really, but it was/is still very much Sun's choice to create the license incompatibility.
Even were that not the case, it's not clear that DTrace could work as well and in the same way in Linux, given the lack of stable internal kernel API in Linux. It'd probably have to be treated like DebugFS, ie "not part of the API, things may change name or break without notice".
License and techical issues aside, though, there's certainly a fair bit of NIH mentality in the Linux kernel circles. Some of it seems to make a lot of sense, in that you'll get a much cleaner system if you're not integrating code full of compatibility adapter interfaces and unnecessary layers of abstraction. Also in that sometimes "someone else is using it this way over here" isn't a good enough reason to use something - for example, if it's crap designed by a collective of baboons with keyboards. Some of the issues, though, do seem a lot like pure and simple NIH.
I don't think that's the case with DTrace, though.
Posted Jan 25, 2010 15:10 UTC (Mon)
by drag (guest, #31333)
[Link] (10 responses)
Posted Jan 25, 2010 15:34 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
more than that, the GPL only kicks in when you distribute the result. so you could combine them with no problems at all, as long as you don't distribute the result (and 'you' can be a company, which can 'distribute' the result internally with no problem, just not to a separate legal entity)
Posted Jan 25, 2010 17:35 UTC (Mon)
by njs (subscriber, #40338)
[Link]
Posted Jan 25, 2010 21:11 UTC (Mon)
by paulj (subscriber, #341)
[Link] (7 responses)
Even if the Linux developers wanted to incorporate Dtrace they
could
not legally do so until Sun creates a legal exception for them. And, no, a Sun
employee stating in a blog that they "as far as they know would not sue"-
type
statement is not legally binding.
Sighage.. This is just waffle. Linux developers do NOT need anything from Sun.
The "only" agreement that is needed is entirely between Linux developers -
they'd need to agree to not sue each other for relying on CDDL code. It's not
in Suns' power to create such an exception. The only thing that would be in
Suns' power is to relicence OpenSolaris under a GPL compatible
licence (such as the GPL).
(Disclaimer, I'm a former employee of the Sun Solaris group).
Posted Jan 25, 2010 21:57 UTC (Mon)
by njs (subscriber, #40338)
[Link] (6 responses)
This is nonsense, even by your argument. Sun is a copyright holder on parts of Linux, and they would need to change their license on those parts to add your proposed "CDDL exception". It would be a lot easier for them and everyone else if they modified the CDDL itself, of course. They've chosen to do neither, and instead blame those dumb Linux folks who went back and time and set up a licensing system (GPLv2 with widely distributed copyright ownership) that is incompatible with the CDDL, and could not possibly be made compatible with the CDDL, before the CDDL was even written! We'd love for them to use DTrace, it's those Linux idiot's lack of foresight that's the problem!
Sorry for getting testy, but this exact same argument -- with the exact same arguments from Sun apologists, all of which serve to confuse the issue despite being utterly without merit -- keeps playing out over and over and it is boring. I'm sure you believe what you're saying, but you're working from a flawed assumption, which is that "Linux developers" are some sort of unified team comparable to your old Solaris group. "Linux developers" are a wildly diverse lot, often competing with each other and with Linux itself (cf. SCO, MS, Sun, ...), and are held together not by a shared vision but by the very licensing regime that you're saying should be adjusted to match Sun's weird licensing ideas.
Posted Jan 26, 2010 9:57 UTC (Tue)
by paulj (subscriber, #341)
[Link] (5 responses)
Sun, in the context of any Linux copyrights it holds, still has no power to give
That's beside the point though. The point is that that Linux developers are
Now I have to say that I was a bit disappointed too that Sun didn't go with
The main point is that, while Sun may once have flirted with your mother, Sun
But why let reality get in the way of Sun bashing? :)
Posted Jan 26, 2010 10:57 UTC (Tue)
by njs (subscriber, #40338)
[Link] (3 responses)
I'm more annoyed at people like trasz, actually, who just had to jump in and explain that no, DTrace's license incompatibility wasn't due to a strategic decision on Sun's part, it was due to problems with Linux's licensing.
I believe the following statements are true: Sun open-sourced much of their code in an attempt to join the FOSS community, because they believed there were benefits in terms of goodwill, contributions from external developers, etc. When doing so, they wrote a license for OpenSolaris that was designed at least in part with the explicit goal of keeping OpenSolaris code out of Linux. Since there's some tension in their framing themselves as an open OS company while declining to share their code with the most important existing open OS, there are some people at Sun who have at various times tried to obfuscate the intentions behind the wording of the CDDL, the avoidance of questions about ZFS patents, etc., by implying that their intention was to share the code with everyone, and if that isn't happening, then it's somehow those Linux guys fault and has nothing to do with them. Any objections to this?
I don't see how any of that's Sun bashing -- I can come up with examples of much worse corporate behavior if you like :-). It's all perfectly logical given their necessities, and I absolutely think that they were within their rights in all of that. They don't owe me anything.
But I do find it annoying that Sun has tried to mislead me (e.g., into treating them like they're some great FOSS hero, *while* they in practice decline to release their code in a form that's usable to me), and even more annoying that one can't even talk about their those reasonable strategic decisions without random third parties showing up to cloud the air with obfuscatory rhetoric. Or something like that.
Posted Jan 26, 2010 11:59 UTC (Tue)
by paulj (subscriber, #341)
[Link] (2 responses)
When doing so, they wrote a license for OpenSolaris that was
designed at least in part with the explicit goal of keeping OpenSolaris code
out of Linux.
Only a few people know whether or not this was the prime consideration, and
they're
mostly not talking (Danese Cooper is, her account is disputed by Simon Phipps). However you
then also have to completely ignore the reality that there are further,
reasonable considerations that have absolutely nothing to do with Linux and
which officers and high-profile engineers have said went against the GPLv2 for
Sun
(ability for ISVs to continue to ship proprietary addons; dispreference for risk
of licence forks with dual-licensing; a perceived requirement for patent
protection clauses).
As for open-source heros, the world is far more than just the Linux kernel
surely? I'm pretty sure there's tonnes of general Unix user-space
code
which Sun have contributed. I'm sure there are other significant ideas and
protocols which are now implemented in Linux.
Yes, it'd be nice to see more integration and code-sharing between
OpenSolaris and the other Unixes, I wrote as much in my last
Sun blog post. I wonder if Oracle will manage to draw down this, one of
the last remaining fronts of the Unix wars, and get us to a less antagonistic
and more productive meeting of the minds of core Unix hackerdom?..
Posted Jan 26, 2010 14:18 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
Linux has other code in it that's dual licensed, and it's the common practice to maintain that dual license over time. The assumption is that if you are submitting a patch to a file, your patch is under the same license(s) as the rest of the code in that file (except for things that would require copyright assignments). I believe that I have seen patches that explicitly were only under one license on a file that was previously multi-license rejected for this reason. No, this would not let Sun re-license this code as they would not have the copyright assignment for it, but that's one of the realities of opensource.
Sun chooses not to do this. They have the right to do so. The fact that they make this choice disappoints me, but does not annoy me.
I don't think anyone is claiming that keeping opensolaris code out of linux was a prime consideration, but I think that it's pretty clear that it was _a_ consideration.
Like others, I do find it annoying when people make the statement that if Linux only changed it's license they could use X and therefor the fact that feature X is not in linux is solely the fault of the linux developers Because Sun made the code freely available and is disappointed that the linux developers are not using it (usually with some snide comment about nih syndrome)
also note that if the CDDL cannot be combined with the GPL, there's no way that it could legally be combined with BSD code with the result still being BSD (it could be combined with BSD code with the result being CDDL)
Posted Jan 26, 2010 18:37 UTC (Tue)
by paulj (subscriber, #341)
[Link]
It's pretty clear even from external information on the net that the OpenSolaris
Anyway, this may well all be irrelevant now as it seems someone went and
Posted Jan 26, 2010 22:41 UTC (Tue)
by xoddam (guest, #2322)
[Link]
http://lmgtfy.com/?q=paulj+341+site%3Alwn.net
Posted Jan 25, 2010 12:55 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
I.e. an integrated tracing system for userspace and kernel programs. From what I see, my wish won't be real for quite a some time.
SystemTap really looked nice, but if it's not going to be merged into the kernel, I won't bother start using it.
Posted Jan 25, 2010 18:20 UTC (Mon)
by adobriyan (subscriber, #30858)
[Link] (3 responses)
This sentence could be automatically added to every post mentioning DTrace
> I.e. an integrated tracing system for userspace and kernel programs. From
Now let's define what "integrated tracing system" means.
Posted Jan 25, 2010 19:41 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Jan 26, 2010 11:09 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
However, questions like 'why is my PostgreSQL backend suddenly spending most of its time doing IPC to nothing obvious' are basically impossible to answer now without killing the backend and hacking the source code, which would tend to perturb the answer because whatever perturbation of dynamic state was causing this would necessarily be lost when the process was restarted. With systemtap/dtrace annotations and a few taps in easy (even for kernel idiots like me) to figure out places in the kernel, it was trivial to answer.
Posted Jan 26, 2010 22:52 UTC (Tue)
by fuhchee (guest, #40059)
[Link]
Would you mind posting more details about your story?
Posted Jan 26, 2010 19:09 UTC (Tue)
by fuhchee (guest, #40059)
[Link]
Systemtap itself does not require integration into the kernel tree in order to operate, so don't hold back. This fact appears to bother some sufficiently to impede acceptance of other kernel infrastructure that, among other valid uses, also happens to help users of systemtap.
A uprobes addendum
And with that, I agree with Linus.
A uprobes addendum
A uprobes addendum
kprobes, dynamic probes, etc.
A uprobes addendum
A uprobes addendum
A uprobes addendum
which is already in.
A uprobes addendum
A uprobes addendum
>>> Sun had two choices - either release the code under GPL, making it pretty much impossible to use by everyone except Linux, or release it under more sane copyleft license that doesn't create additional hurdles for end users.A uprobes addendum
Have you heard, just for example, about Firefox disjunctive tri-license ?
They would have been able to choose a similar solution but Sun chose deliberately to prevent the inclusion of DTrace in Linux.
A uprobes addendum
NVidia can get away with what it does - producing a binary module with
a
GPL wrapper - only because its code doesn't need to touch too much of the
kernel and doesn't need to modify core routines.
A uprobes addendum
Nvidia can probably get away with what it does because the Nvidia kernel
module is not, as far as anybody can tell, derivative of the Linux kernel.
"Derivative" is a legal term defined in USA copyright law and it indicates
were your copyrights rights end when dealing with other parties. If you did
not make it and it is not a derivative then there is no way any of your
GPL'd software could have a effect on it.
Apparently Nvidia kernel module is mostly Windows driver shoehorned into
Linux via the "GPL Wrapper". This sort of thing is very gray
legally and
somebody could challenge it and get it decided in court, but no copyright
holder in the Linux kernel has decided to do that. This "grayness" is
built into the system.. legal stuff is not programming stuff. It is
designed to allow flexibility.
HOWEVER if you take Solaris Dtrace code and plunk it into the kernel, and
then ship it, then your creating a derivative product of both Solaris and
Linux. Therefore you will be forced to deal with licensing issues and need
to provide a license for your product that will incorporate the licenses of
both copyright holder's requirements.
The CDDL is incompatible with GLv2-only code due to the additional
restrictions that the CDDL places on code that the GPLv2 does not allow.
The CDDL restrictions are not bad, they have to do with patent stuff, but
they exist and are in conflict with the wording of the GPL license.
That is all there is to it. You could probably combine the two and get away
with it just fine, but it is not something that a company is going to base
their ability to legally ship Linux on and kernel programmers are going to
put a lot of effort into.
The CDDL was designed to do this on purpose* and it is there to allow Sun
to produce a competitive product to Linux. They need to create product
differentiation between Linux and Solaris and Dtrace/ZFS is just about the
only way they can do it.
* The CDDL is based on the Mozilla license. The Mozilla license is
noteworthy (in this discussion) _because_ it created licensing conflicts
with GPL software in the past. Which is why, of course, Mozilla has gone
out of their way and legally stated that the GPL is compatible by
dual/triple licensing their code. (Mozilla/GPL/LGPL)
Even if the Linux developers wanted to incorporate Dtrace they could not
legally do so until Sun creates a legal exception for them. And, no, a Sun
employee stating in a blog that they "as far as they know would not sue"-
type statement is not legally binding.
A uprobes addendum
A uprobes addendum
A uprobes addendum
A uprobes addendum
A uprobes addendum
on LWN. It's a shame LWN comment history isn't open, as I could then point
you to mine.
an exception to the Linux kernel generally. In the hypothetical event that all
others agreed that linking with CDDL was allowed and it came down to Sun,
I'm not sure their disagreement is even possible. That'd be an IANALing
session though.
not organised, and that Linux has no way to manage its copyrights. This was
simply NOT Suns' problem - not of its making and it was never Suns' problem
to fix. Worse, despite the years of whining about how evil Sun was to not
licence its code to Linux and how impossible it would be for the Linux
developers to solve their own problems, Linux HAS had at least one
suspiciously licence-change like event in recent times (and Linux was in SCM
already at that point, so all the rights holders should be easyish to trace). So
it seems the impossible isn't quite as impossible as claimed.
the GPL. I think Sun could have been bolder and tried to be more inclusive,
but hey...
is not your daddy and so it was never Suns' fault that you didn't get your pony.
A uprobes addendum
A uprobes addendum
A uprobes addendum
A uprobes addendum
(whose code likely is running on a good proportion of Linux machines) and who
was involved at a high-level with the open-sourcing of Solaris has
philosophical objections to dual-licensing - nowt to do with Linux. Also, a good
few Sun engineering folk have BSD backgrounds, and the BSD folk have not
always had good experience with how dual-licensing worked out for them with
BSD/GPL code that was part-maintained by Linux.
licensing decision had *several* dimensions to it. Only one, at best, was about
Linux.
bought the pony.
LWN comment history
> point you to mine.
A uprobes addendum
A uprobes addendum
functionality.
as a signature :)
what I see, my wish won't be real for quite a some time.
A uprobes addendum
A uprobes addendum
A uprobes addendum
A uprobes addendum