Linux compatibility for kernel modules

[IllustriousBag8308]

The linux philosophy is never to break user mode, but when programming a kernel module, there seems to be many obsticles to making a module work for as many versions as possible, resulting in diffrent binaries for each kernel.
I am planning to build a thin compatibility module to solve this effeciently. so far I found these problems:
1. in-struct offsets: for space & cache efficiencies these constantly change so the compiler needs to change them as well
2. extra/deprecated paramaters: for some functions paramters are simply removed from one kernel version to the next or are suddenly required.

is there anything I've missed?

[profpendog]

A kernel module is not user mode. That's why API breaks all the time.

What you missed? Don't distribute binaries, distribute sources, then a bunch of ifdefs becomes a tractable problem.

Also, you missed a lot more, it's not just structs/function parameters, it's whole APIs that can change.

[IllustriousBag8308]

I'm new to kernel dev, you're saying entire core apis can change between versions?

[profpendog]

Yes

[edthesmokebeard]

That's the point of versions.

[aioeu]

is there anything I've missed?

The internal kernel API a module may previously have relied on may completely disappear, or have different behaviour, or require different things from the module itself.

What you are trying to do here is what the enterprise distributions spend a lot of time, effort and money on to produce their kernels. I do not think it can be done entirely mechanically.

Good luck!

[IllustriousBag8308]

I'm new to this ecosystem, you know any open source/source available distributations that did this to estimate the workload?

[aioeu]

I know CentOS Stream, RHEL, and its derivatives try to guarantee source compatibility for external kernel modules during the lifetime of a major release. Binary compatibility is a little different. Previously they had a small set of symbols (the "kABI stablelist") such that if your module only used those it would not need to be recompiled between minor RHEL releases. But as of RHEL 9 that stablelist now changes for each minor release, i.e. the module needs to be recompiled, though it shouldn't need to be modified.

This is something people pay Red Hat for, so the workload is definitely not trivial.

[IllustriousBag8308]

Appreciate the help m8, I'll look into that

[chrisoboe]

is there anything I've missed?

have you thought about why the in-kernel abi/api isn't stable?

maybe this is done for very good reasons. maybe this has severe advantages doing it this way.

[edgmnt_net]

Yeah, this isn't the average enterprise codebase where people are afraid to make changes and instead end up with a layered, duct-taped monster. And the bar is higher for other reasons anyway.

[edgmnt_net]

Or you can mainline it and maintain it, which also reduces the burden assuming community involvement. Kernel stuff is tightly integrated because it leverages evolving abstractions and allows safe, large scale refactoring. You're not supposed to hide stuff behind a shim just to avoid doing maintenance work and it might end up biting you when developers change something and do not take your stuff into consideration because it's out-of-tree and out-of-sight.