21–24 of 24 posts
Earlier quoted context omitted.
Is this because they are also using Linux or do they plan to use it on FreeBSD?
Those aren’t mutually exclusive options.
There are some projects to bring BPF features needed (generally called eBPF) to FreeBSD, such as https://github.com/YutaroHayakawa/generic-ebpf - but there's no accepted mainline implementation as of yet.
1. Obviously Linux-only. How is it DTrace 2.0? 2. That’s a staggering amount of NIH, from CTF to syntax. Why?
2. bpftrace is built from the ground-up to operate with eBPF, which does much more than DTrace. I made a list in the post, and that's only happened in the last two years. I understand that if I'm narrowing eBPF to just DTrace vs bpftrace comparisons, you might question why we're doing all this, but consider the bigger picture of eBPF.
Is there any chance this tool or maybe a wrapper for it could get a higher level, less C-like syntax?
The 2 major problems (ie the Elefant in the room) compared to DTrace are missing: 1. security: eBPF still supports arrays and and is therefore inherently insecure to be used in the kernel. DTrace didn't support that feature on purpose and not because they couldn't do it. see spectre/meltdown. 2. availability: eBPF probes only work within the kernel. DTrace extends the same interface to the libc level and the user spa…
Hmm, looks like you are missing some crucial details, eBPF has the same mitigations to the CPU bugs in place as the rest of the kernel (e.g. retpolines on tail calls, index masking for arrays, sanitation of speculative store bypass, etc). Also, eBPF probes do not only work in the kernel but user space as well via uprobes as one example.
2nd: do you see uprobes supported anywhere? I still can only use DTrace with high level languages. and I wouldn't use this island solution anyway. DTrace works everywhere, now even on windows. eBPF is Linux-only. And should have stayed netfilter only BTW.