
Dtrace for Linux - espadrine
https://gnu.wildebeest.org/blog/mjw/2018/02/14/dtrace-for-linux-oracle-does-the-right-thing/
======
brendangregg
Unfortunately for DTrace, this is too late. Oracle should have done this years
ago. Now Linux has a more powerful tracer builtin, eBPF, and it would be a
backwards step to switch the kernel code to DTrace (assuming the DTrace port
is completed, which it is not). I'm sure this will not be lost on the
maintainers, who have the ultimate say as to what is included in Linux
mainline.

The only hope for DTrace is to have the frontend emit BPF bytecode. The bulk
of this GPL DTrace code is no longer needed, only the user-level front end.

~~~
burke
As a non-expert, I still find this exciting. While eBPF may be more powerful,
I find it far less approachable than DTrace. Perhaps this is just a failure to
discover the right documentation. I use DTrace now and then on macOS and have
resented that I can't really use it on Linux as well.

~~~
nailer
IIRC one of the big things about dtrace vs systemtap is that dtrace could
trace a process from userspace to kernel space and then back again. Can eBPF
do this? How else do they compare?

~~~
brendangregg
That would not be recalling correctly: SystemTap does that, and so does eBPF
(via uprobes and kprobes).

A large problem with SystemTap is that it was developed in the open, and in
the early days people were scared off with its kernel panics. SystemTap built
a negative brand: first impressions matter. DTrace, however, was largely built
before its public release, and with the help from many other engineers and
test teams. People's first impressions with DTrace was something that was
already awesome. Of course, there are other problems with SystemTap: its
process of compiling code and loading kernel modules was always risker than an
interpreter.

As for how eBPF compares: I summarized it last year
[http://www.brendangregg.com/blog/2016-10-27/dtrace-for-
linux...](http://www.brendangregg.com/blog/2016-10-27/dtrace-for-
linux-2016.html)

~~~
fche
> and in the early days people were scared off with its kernel panics.

It is ironic that to this day those kernel panics are associated with
systemtap (the visible user interface) rather than the kernel (where the vast
majority of the responsible bugs actually lay). But perceptions indeed matter,
even erroneous ones.

------
bcantrill
I had somehow missed this; this is excellent news! The Oracle port of DTrace
to Linux is (far and away) the most complete port; Kris van Hees and team did
a very thorough job[1], and I'm elated (and honestly, surprised) that they
somehow prevailed on Oracle to do the right thing here!

[1]
[https://www.youtube.com/watch?v=NElog3MvUC8](https://www.youtube.com/watch?v=NElog3MvUC8)

~~~
rhinoceraptor
If ZFS were also relicensed, would Illumos be able to relicense OpenZFS as
well, even with the divergence?

~~~
4ad
OpenZFS can't be relicensed as GPL since FreeBSD won't be able to use it.

Perhaps it could be dual-licensed, not sure, but that would be bad for FreeBSD
as well. If it would be integrated into the mainline Linux kernel, I don't
believe FreeBSD could merge back subsequent ZFS changes done on the Linux
side.

If OpenZFS were relincensed and developed outside the mainline Linux tree (as
it is now), FreeBSD would be able to get all changes, but it would still be
annoying to actually use ZFS in Linux for the same reason it is annoying to
use it now, even though the legal uncertainties would disappear.

~~~
insertnickname
FreeBSD is OK with CDDL but not GPL?

~~~
boomboomsubban
Yeah, the CDDL is weak copyleft, meaning derived works don't need to be
licensed CDDL. The GPL is strong copyleft, and could force all of FreeBSD to
adopt the GPL.

~~~
LukeShu
To clarify that a bit: The CDDL is a per-file copyleft; you must provide the
sources of the CDDL-licensed source files. The GPL is a per-program copyleft;
you must provide the sources of the entire program if it contains GPL-licensed
code; the source of the entire program effectively becomes GPL-licensed if you
incorporate GPL-licensed code.

If I made a closed derivative of the FreeBSD kernel, I'd have to provide the
(CDDL) ZFS sources, but nothing else. If ZFS were GPL, I'd have to provide the
sources to the entire kernel.

------
jsiepkes
Really cool! However isn't it a bit too late for DTrace to gain market share
on Linux now SystemTap and all have gotten such a head start?

For me personally I like the idea of being able to use my DTrace skills (which
I gained on FreeBSD and SmartOS) on Linux!

~~~
severino
Well, it's never too late!

I mean, when reading articles like this one:

[http://www.brendangregg.com/blog/2015-07-08/choosing-a-
linux...](http://www.brendangregg.com/blog/2015-07-08/choosing-a-linux-
tracer.html)

Linux tracing looks like a mess, where there're dozens of incompatible
alternatives, each one with its gotchas. But instead, dtrace is a mature
standard framework which also works under BSD or macOS. You got one
programming language, D, and tons of resources out there.

So... my best wishes for this.

~~~
lscotte
It was a mess back then - in 2015. Instead, it's probably more useful to look
at at where things are today rather than assuming things are the same as they
were a few years ago. Things move fast in this space - for example, just a
year later Brendan wrote this on eBPF:
[http://brendangregg.com/blog/2016-10-27/dtrace-for-
linux-201...](http://brendangregg.com/blog/2016-10-27/dtrace-for-
linux-2016.html)

------
benmmurphy
it looks like the dtrace port can be used by non-privileged users (i'm just
guessing because there is some uid checks in there). just be aware there has
been a bunch of fixes applied to the illumos version of dtrace and i'm pretty
sure at least 1 (maybe more) have not been applied to this version.

------
paride5745
Time for ZFS now!

Even better yet, a new OpenSolaris under GPL instead of CDDL.

~~~
snw
The new OpenSolaris is called illumos.

And the CDDL is actually fine. Give it a try :)

~~~
paride5745
I use OpenIndiana since its beginning, it's fine but IMHO not there for
serious work. FreeBSD with ZFS is miles ahead.

And the CDDL is not fine, as it is not compatible with GPL, which makes it
impossible to have it official in the Linux kernel.

------
alberth
What does this mean for DTrace on FreeBSD?

Given that DTrace is now GPL'ed, does that kill DTrace on FreeBSD?

[https://wiki.freebsd.org/DTrace](https://wiki.freebsd.org/DTrace)

~~~
floatboth
You can't retroactively revoke CDDL :)

And new DTrace userspace is actually under the Universal Permissive License
now (which is, well, permissive). The Linux kernel module is GPL. I don't
think FreeBSD needs anything from that module at all.

~~~
stock_toaster
The UPL license also has some somewhat "unique" patent grant wording with
regard to a "Larger Works" file, which can even reference external projects by
name, and its supposed use as a CLA document.

Not being a lawyer (and similarly not a licensing or IP subject matter
expert), and know the license was drafted by Oracle, I am somewhat suspicious
of it.

------
luvpreet33
Have you tried Sysdig?
[https://github.com/draios/sysdig](https://github.com/draios/sysdig)

------
krylon
This is good news, I think.

I have heard so many people praise DTrace, but it not being available on Linux
has so far kept me from looking at it. I have one FreeBSD box at home, one
(ancient) laptop running OpenBSD, but all my other machines run various Linux
distros. So there was little point for me to spend any time learning it.

Now there is. :D I think I know what I will be doing with my next vacation.

------
rurban
Thanks God, eBPF is a security nightmare as we saw with Spectre, they even got
arrays now. and there is no infrastructure as with dtrace. Will compile it
into my kernel for sure for proper dev work.

~~~
chatmasta
Doesn't this criticism apply to any software that opens a communications
channel between the kernel and user space? Also, how does eBPF relate to
Spectre?

~~~
rurban
Yes, but syscalls are properly designed. drivers are a huge problem, always
have been. eBPF on the other hand lacks proper security design. They added it
afterwards, to some extent.

> how does eBPF relate to Spectre?

Please read any spectre paper. Besides the known javascript attacks, eBPF is
the easiest way to bypass kernel ASLR. google is your friend.

