3 ms·

It strikes me that the Linux position of "we won't provide a stable binary driver interface to force you to mainline your device drivers" is a kind of spiritual

It strikes me that the Linux position of "we won't provide a stable binary driver interface to force you to mainline your device drivers" is a kind of spiritual opposite to dynamically linking shared libraries. One of the most common arguments in favor of shared libraries is that you can patch libraries without rebuilding everything under the sun, but the mechanism used for that is in fact a stable binary interface that the Linux kernel itself refuses to provide. So, if nothing else, Linus taking this position on shared libraries is extremely consistent.

jchw 6y ago
I do think usermode and kernelmode concerns are different, because the kernel drivers are basically the libraries or extensions, not the program itself. If you statically link a driver with the kernel, you get a kernel. If you statically link Qt with your GUI application, you get your GUI application. The kernel moves fast, because it has to. The usermode does not. The libc interface and relevant syscalls are backwards compatible to a greater degree than would ever be reasonable with kernel drivers. Windows does the best here arguably and drivers still had to break a few times in the past couple decades — not All drivers, but certainly some. I guess the fuller picture to me would need to acknowledge the difference between modular plugins, library dependencies, and programs, as well as the difference between kernel and userland. The latter is definitely important: it’s very rare in userland that your CPU vendor matters over just the ISA itself, but in privileged/supervisor mode, often there are more differences directly exposed, as one example of potential pitfall. I think this sortof exemplifies the increased responsibility of the kernel to keep drivers working through refactors and changing hardware, especially on Linux where the hardware support is extremely diverse. I do still agree with Linus regarding dynamic libraries, but I also think the two cases make sense for different reasons.
- BugsJustFindMe 6y ago
  > Windows does the best here arguably By a light-year. > and drivers still had to break a few times in the past couple decades Like 2 times in the past, what, 20 years?
  - jchw 6y ago
    Somewhere around that mark (it was 3 when i responded, i believe that is more close to the truth,) maybe more for graphics drivers. Of course, that’s with Microsoft’s legendary commitment to backwards compatibility, more limited scope in which devices Windows targets, and a driver model specifically designed to provide a stable interface. Linux doesn’t attempt to provide a stable driver model, but based on the fact that many users are stuck on old kernels due to unmaintained drivers, I’m not sure if it would really help that much if it did. Desktop PCs are the place where drivers are most likely to be maintained long term and thats a small part of the Linux install base. The dynamics differ more in the wide range of supported devices.
eschaton 6y ago
Nah, it’s just obstinance. Providing a stable kernel driver ABI would not actually be difficult, but when you’ve dug in your heels about it for 25 years admitting just how obviously and blatantly wrong you were can be difficult.

jchw 6y ago

I do think usermode and kernelmode concerns are different, because the kernel drivers are basically the libraries or extensions, not the program itself. If you statically link a driver with the kernel, you get a kernel. If you statically link Qt with your GUI application, you get your GUI application. The kernel moves fast, because it has to. The usermode does not. The libc interface and relevant syscalls are backwards compatible to a greater degree than would ever be reasonable with kernel drivers. Windows does the best here arguably and drivers still had to break a few times in the past couple decades — not All drivers, but certainly some. I guess the fuller picture to me would need to acknowledge the difference between modular plugins, library dependencies, and programs, as well as the difference between kernel and userland. The latter is definitely important: it’s very rare in userland that your CPU vendor matters over just the ISA itself, but in privileged/supervisor mode, often there are more differences directly exposed, as one example of potential pitfall. I think this sortof exemplifies the increased responsibility of the kernel to keep drivers working through refactors and changing hardware, especially on Linux where the hardware support is extremely diverse. I do still agree with Linus regarding dynamic libraries, but I also think the two cases make sense for different reasons.

BugsJustFindMe 6y ago
> Windows does the best here arguably By a light-year. > and drivers still had to break a few times in the past couple decades Like 2 times in the past, what, 20 years?
- jchw 6y ago
  Somewhere around that mark (it was 3 when i responded, i believe that is more close to the truth,) maybe more for graphics drivers. Of course, that’s with Microsoft’s legendary commitment to backwards compatibility, more limited scope in which devices Windows targets, and a driver model specifically designed to provide a stable interface. Linux doesn’t attempt to provide a stable driver model, but based on the fact that many users are stuck on old kernels due to unmaintained drivers, I’m not sure if it would really help that much if it did. Desktop PCs are the place where drivers are most likely to be maintained long term and thats a small part of the Linux install base. The dynamics differ more in the wide range of supported devices.

eschaton 6y ago

Nah, it’s just obstinance. Providing a stable kernel driver ABI would not actually be difficult, but when you’ve dug in your heels about it for 25 years admitting just how obviously and blatantly wrong you were can be difficult.