Why Does My eBPF Program Work on One Kernel but Fail on Another? ebpfchirp.substack.com 54 points by musha68k 6 hours ago
linuxftw 16 minutes ago This is all covered in the eBPF documentation. CORE was introduced over 6 years ago.
jeffrallen 3 hours ago Feels like yet another example of "essential complexity driven by too much churn in infrastructural code".I wonder why no one needs to write this article about dtrace probes? Is it because they are less used? Less capable? More stable? Better engineered?Probably all of the above, alas. heinrichhartman an hour ago From my experience most DTrace users rely on DTrace "providers" [1] and Static Trace Points [2] rather than directly probing kernel structs. Also these days the Solaris kernel is not moving all that much.[1] https://www.illumos.org/books/dtrace/chp-syscall.html#chp-sy... [2] https://www.illumos.org/books/dtrace/chp-sdt.html#chp-sdt
heinrichhartman an hour ago From my experience most DTrace users rely on DTrace "providers" [1] and Static Trace Points [2] rather than directly probing kernel structs. Also these days the Solaris kernel is not moving all that much.[1] https://www.illumos.org/books/dtrace/chp-syscall.html#chp-sy... [2] https://www.illumos.org/books/dtrace/chp-sdt.html#chp-sdt
There's some research on this topic, e.g., https://depsurf.github.io
This is all covered in the eBPF documentation. CORE was introduced over 6 years ago.
Feels like yet another example of "essential complexity driven by too much churn in infrastructural code".
I wonder why no one needs to write this article about dtrace probes? Is it because they are less used? Less capable? More stable? Better engineered?
Probably all of the above, alas.
From my experience most DTrace users rely on DTrace "providers" [1] and Static Trace Points [2] rather than directly probing kernel structs. Also these days the Solaris kernel is not moving all that much.
[1] https://www.illumos.org/books/dtrace/chp-syscall.html#chp-sy... [2] https://www.illumos.org/books/dtrace/chp-sdt.html#chp-sdt