Hacker News Reader

Comment by ak217 | Hacker News Reader

The Linux kernel has an incredibly strong userspace API stability guarantee. I think in practice this guarantee is unmatched in modern computing, and it's what allows things like containers to deliver such incredible long term value.

Software is defined by its interfaces, and unlike userspace APIs, this guarantee does not apply to internal kernel APIs. The ability to update the latter is what enables the former. Inability to update internal implementation details inevitably leads to ossification and obsolescence of the whole system. Linus Torvalds spoke about this recently in the context of new Rust code in the kernel.

View on HN

>Inability to update internal implementation details inevitably leads to ossification and obsolescence of the whole system.

No, in practice I think it leads to growing complexity, because the system then adds additional APIs (e.g., v1, v2, v3, etc.) to support new features, but has to continue to maintain the old APIs for backwards compatibility, leading to lots of extra code and a huge maintenance burden.

Yes, precisely. The escalating complexity, maintenance burden and constraints eventually cause the whole system to lose momentum, lose support and become obsolete.

Like winapi with its ...Ex and numbered functions (NdrClientCall4).

Or Linux with it's numbered syscalls (dup, dup2, dup3).

> Linux kernel has an incredibly strong userspace API stability guarantee

These guarantees are not that strong, unfortunately. For example, API between kernel-mode and user-mode halves of the GPU driver is unstable. To have 3D accelerated graphics on RK3288 you gonna need either libmali-midgard-t76x-r14p0-r0p0-gbm.so or libmali-midgard-t76x-r14p0-r1p0-gbm.so userspace library, depending on a minor hardware revision of that RK3288.

Is there some reason that the Linux kernel couldn't offer a stable API for device drivers? At least for common types of devices. Would that really lead to ossification? Stable APIs usually make it easier to change code at lower levels.

> Is there some reason that the Linux kernel couldn't offer a stable API for device drivers?

Politics. Offering a stable-ish internal API would instantly lead to hardware vendors shipping closed source drivers for Linux.

Currently, you have to be the size of NVIDIA or AMD to be able to afford a closed source driver, it's simply a huge work to keep up with the constant improvements in the Linux kernel.

Not true, there are smaller companies providing closed source kernel modules as well. Check any Android image for a device with SD card slot in the era where open source exfat driver didn't exist, and you'll likely find one of the 2 proprietary exfat driver modules.

Embedded/mobile projects don't tend to use bleeding-edge kernels and stuck on one version regardless of closed source modules anyway.

Yeah and these closed source exfat drivers were a true pain to maintain which is why Paragon (one of the vendors) was pretty pissed when Samsung's driver was upstreamed to Linux [1] - it killed off their business.

[1] https://arstechnica.com/information-technology/2020/03/the-e...

Reply on news.ycombinator.com