3 ms·

There's upsides and downsides to both approaches. I think that Linux kernel maintainers continue this approach because this forces driver maintainers to meet a

There's upsides and downsides to both approaches. I think that Linux kernel maintainers continue this approach because this forces driver maintainers to meet a minimum level of effort to get their work merged.

joecool1029 3y ago
Theoretically the monolithic approach is supposed to be more performant. Abstracting away everything into modules can be more stable, but also usually incurs some overhead. But this is holy war territory and I'm trying to ELI5 best as I can.
rwmj 3y ago
One serious downside (for end users) of having a stable driver ABI would be that manufacturers would release a binary blob driver for their hardware which just about works, but no bug could ever be fixed. Manufacturers wouldn't have any incentive to fix bugs and kernel developers couldn't do it either. The situation of GPL'd drivers in a kernel with an unstable ABI wasn't really planned, but for users it's probably the best outcome.
- nuancebydefault 3y ago
  I always thought that ABI was the interface between CPU and executable code, ie the spec of the assembly language for a CPU architecture: aarch64, x86 etc. I now would guess it is also a term used for the interface between libraries (kernel/driver) as long as they are binary (without the source code or headers) ?
  - gdprrrr 3y ago
    It's also used for programming languages like Rust and Haskell. The Rust compiler not having a stable ABI means the way the compiler stores information about function signatures, debug symbols etc in libraries may change between compiler versions, so you have to recompile all libraries.
  - rwmj 3y ago
    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/master/raw/x86-64-ABI/abi.pdf?job=build https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/ma... https://www.agner.org/optimize/calling_conventions.pdf 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-guarantee-for-C-plugins https://libguestfs.org/nbdkit-plugin.3.html#API-and-ABI-guar... https://gitlab.com/nbdkit/nbdkit/-/blob/9f96d53dbbbf67ae5ed0acb2ef8887709c47d3cc/include/nbdkit-plugin.h#L44-L153 https://gitlab.com/nbdkit/nbdkit/-/blob/9f96d53dbbbf67ae5ed0...

joecool1029 3y ago

Theoretically the monolithic approach is supposed to be more performant. Abstracting away everything into modules can be more stable, but also usually incurs some overhead. But this is holy war territory and I'm trying to ELI5 best as I can.

rwmj 3y ago

One serious downside (for end users) of having a stable driver ABI would be that manufacturers would release a binary blob driver for their hardware which just about works, but no bug could ever be fixed. Manufacturers wouldn't have any incentive to fix bugs and kernel developers couldn't do it either. The situation of GPL'd drivers in a kernel with an unstable ABI wasn't really planned, but for users it's probably the best outcome.

nuancebydefault 3y ago
I always thought that ABI was the interface between CPU and executable code, ie the spec of the assembly language for a CPU architecture: aarch64, x86 etc. I now would guess it is also a term used for the interface between libraries (kernel/driver) as long as they are binary (without the source code or headers) ?
- gdprrrr 3y ago
  It's also used for programming languages like Rust and Haskell. The Rust compiler not having a stable ABI means the way the compiler stores information about function signatures, debug symbols etc in libraries may change between compiler versions, so you have to recompile all libraries.
- rwmj 3y ago
  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/master/raw/x86-64-ABI/abi.pdf?job=build https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/ma... https://www.agner.org/optimize/calling_conventions.pdf 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-guarantee-for-C-plugins https://libguestfs.org/nbdkit-plugin.3.html#API-and-ABI-guar... https://gitlab.com/nbdkit/nbdkit/-/blob/9f96d53dbbbf67ae5ed0acb2ef8887709c47d3cc/include/nbdkit-plugin.h#L44-L153 https://gitlab.com/nbdkit/nbdkit/-/blob/9f96d53dbbbf67ae5ed0...