Comment by masklinn | Hacker News Reader

Comment by masklinn | Hacker News Reader

> Naturally I wanted to get my hands on this stuff to try it out for myself. Is it really as good as they say? Normally I stick to Linux, but it (generally) doesn’t have these Sun technologies.

Since then, bpftrace[0] has been released, supposedly it's actually better than dtrace, in the sense that it's even more capable[1].

See https://www.joyfulbikeshedding.com/blog/2019-01-31-full-syst... for a recent basic ebpf/bpftrace tutorial. Brendan Gregg also has a primer on eBPF: http://www.brendangregg.com/blog/2019-01-01/learn-ebpf-traci...

[0] http://www.brendangregg.com/blog/2018-10-08/dtrace-for-linux...

[1] that's Brendan Gregg saying it: http://www.brendangregg.com/blog/2018-10-08/dtrace-for-linux... — having contributed to it and being one of the leading dtrace experts

> * in the sense that it's even more capable*

Examples? I don't see how it's more capable. Catching up with dtrace, maybe.

bpftrace's potential is higher than DTrace's, but at the moment it's definitely not reached parity. For example: we cannot yet read strings bigger than about 240 bytes (any bigger won't fit on the BPF stack).

The extra capabilities Linux added made it insecure (arrays), so that eBPF needs to be disabled in production SMP systems.

There's also no existing userland support. Everyone provides DTrace probes, no one systemtap probes.

You can trace dtrace probes with ebpf.. see https://github.com/iovisor/bpftrace/blob/master/docs/referen...

BPF is compatible with DTrace probes.

The kernel verifier does extensive bounds checks on array uses and jumps in BPF programs.

Those checks don't save you from spectre-like cache exploitation. DTrace was designed with maps-only for a reason.

Thanksfully there's now Oracle Linux with DTrace-proper.

When the usdt syntax can use static DTrace probes, why isn't it documented then? and why doesn't it use the familiar DTrace syntax then? Why is nobody using it?

> DTrace was designed with maps-only for a reason.

You write this like you are implying that the DTrace designers somehow foresaw that spectre would be a thing and therefore array accesses would be a risk. This is obviously false. I’m sure there are reasonable reasons to not have arrays but predicting spectre 10 years before it was found is not one of them.

Ask Brian, he did it on purpose.

Reply on news.ycombinator.com