Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dtrace for Linux

gnu.wildebeest.org

Post reply on HN
Print view View original

31–40 of 108 posts

Re: Dtrace for Linux

#31

Post by fche »

brendangregg wrote: post #25
nailer wrote: post #23

Earlier quoted context omitted.

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?

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 tea…

> 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.

Re: Dtrace for Linux

#32

Post by drb91 »

brendangregg wrote: post #9

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 th…

Well, none of my dtrace knowledge works with eBPF, and eBPF is only useful on linux. This is still a very welcome change :)

Re: Dtrace for Linux

#33

Post by dmm »

rollcat wrote: post #26
HankB99 wrote: post #20

Earlier quoted context omitted.

> ... but it would still be annoying to actually use ZFS in Linux for the same reason it is annoying to use it now. For those of us who are ignorant of what is annoying to use now (I raise my hand) can you elaborate? I'm fooling around with it on Debian Stretch and Ubuntu 16.04 LTS and haven't yet found it annoying (except for the challenge of finding where the various command line switches are documented...) I was p…

Running ZFS (boot&root) on both Ubuntu 17.10 on my home server and Debian Jessie on my laptop. The ZFS experience between the two is heaven and hell. Ubuntu just ships the zfs.ko and basically everything works 100% of the time, zero effort. Debian OTOH has to compile the module via DKMS for every minor kernel release... You better track those apt upgrades carefully, and run `dkms status` after each one, or you might…

My debian install automatically builds the zfs module during each kernel upgrade.

Re: Dtrace for Linux

#35

Post by rhinoceraptor »

rollcat wrote: post #26
HankB99 wrote: post #20

Earlier quoted context omitted.

> ... but it would still be annoying to actually use ZFS in Linux for the same reason it is annoying to use it now. For those of us who are ignorant of what is annoying to use now (I raise my hand) can you elaborate? I'm fooling around with it on Debian Stretch and Ubuntu 16.04 LTS and haven't yet found it annoying (except for the challenge of finding where the various command line switches are documented...) I was p…

Running ZFS (boot&root) on both Ubuntu 17.10 on my home server and Debian Jessie on my laptop. The ZFS experience between the two is heaven and hell. Ubuntu just ships the zfs.ko and basically everything works 100% of the time, zero effort. Debian OTOH has to compile the module via DKMS for every minor kernel release... You better track those apt upgrades carefully, and run `dkms status` after each one, or you might…

I have a ZFS on root Arch setup, unfortunately Gnome 3 is such garbage nowadays that I hardly ever use it. It still doesn’t do display scaling correctly for 4K and it just crashes all the time.

Re: Dtrace for Linux

#36

Post by viraptor »

brendangregg wrote: post #22
burke wrote: post #19

Earlier quoted context omitted.

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.

eBPF lacks a high level front end, in part because that's optional. Engineering effort has gone into the essentials first: kernel development of eBPF, basic user-level frameworks to use it (bcc), and lots and lots of testing and bug fixes to make that rock solid. bcc is not as easy to code in, but I've been able to port over many of my DTraceToolkit scripts already. We're only more recently looking at higher level la…

Am I reading too much into the last sentence, or are they actually trying to use existing probes with dtrace frontend:

> So with all those techniques now available in the linux kernel it will be exciting to see if dtrace for linux can unite them all.

Re: Dtrace for Linux

#37

Post by floatboth »

brendangregg wrote: post #9

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 th…

How would USDT probes work with a BPF backend?

Re: Dtrace for Linux

#38

Post by floatboth »

alberth wrote: post #34

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

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.

Re: Dtrace for Linux

#39

Post by nordsieck »

Conan_Kudo wrote: post #18
takeda wrote: post #16

Earlier quoted context omitted.

I don't think the license can be done retroactively. I mean Oracle owns copyright to major part of ZFS and they can change license to that. But the contributions done to OpenZFS each developer owns copyright to their own work. I believe the original code could be treated as either CDDL or GPL, but the code that was contributed before license change would still be under CDDL. I think OpenZFS project owners would need…

> Things would be much easier if every author would surrender their copyright to OpenZFS project, but some people might have problem with it since then you surrender all claims to the code. This is super-dangerous. There's a reason that copyright assignment agreements are rare. In a lot of jurisdictions, it's not even possible. Most copyright license agreements instead force unlimited sublicensing grants, which provi…

> There's a reason that copyright assignment agreements are rare. In a lot of jurisdictions, it's not even possible.

How is a software development business possible under those circumstances? In the US one of the core pieces of every employment contract (for software developers) is IP assignment.

Re: Dtrace for Linux

#40

Post by Annatar »

paride5745 wrote: post #3

Time for ZFS now! Even better yet, a new OpenSolaris under GPL instead of CDDL.

That day better never come; If the last thing I dearly love, illumos (there is no OpenSolaris any more) ever gets relicensed under that fascist GPL, I’ll never write another line of code again. That would be the last straw.
Post reply on HN