Why Does My eBPF Program Work on One Kernel but Fail on Another?

Contempt for stable kernel data structures and APIs (and forget about any sort of kernel ABI) might make things easier for certain kernel developers, but it offloads a constant maintenance burden onto many other people, such as eBPF, driver, and kernel extension developers.

This sort of asymmetry is why system modules, and platforms in general, should absorb pain in order to benefit their many clients, rather than doing the opposite.

Could be worse though - some platforms (cough, iOS) are happy to break user apps every year and offload a constant maintenance burden onto many thousands of app developers, when a more stable ABI would save developers (and users) billions of dollars in aggregate.

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.