[rwmj]

ABI is just the name for any binary interface between parts of a program, eg in C there is a well-defined and very long term stable ABI for calling and returning from functions: https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/ma... https://www.agner.org/optimize/calling_conventions.pdf

If you combine that with a stable set of C function names and parameters, then you could define an ABI for kernel device drivers if you (and the Linux developers) wanted. While it sounds like a good idea, the outcome probably wouldn't be great for users.

Stable ABIs work in other places. For nbdkit we defined a stable ABI for plugins and have maintained it for over 10 years, so a binary plugin written for 10 years old nbdkit can be loaded by modern nbdkit just fine (and we test this too). This was done to encourage proprietary modules, because that helps with our wider goal to make all block devices and formats visible through an open, interoperable protocol (ie. NBD). Implementing this wasn't very easy, since we also want to allow the plugin interface to evolve. It involves a bunch of C macros and careful expansion of C structs so earlier fields remain compatible while later fields add the new features. https://libguestfs.org/nbdkit-plugin.3.html#API-and-ABI-guar... https://gitlab.com/nbdkit/nbdkit/-/blob/9f96d53dbbbf67ae5ed0...