Linux Kernel API Changes/Additions

Linux kernel API changes/additions

See kernel API/ABI tracker here: http://abi-laboratory.pro/tracker/timeline/linux/

The analysis was done by the abi-compliance-checker and abi-dumper tools.

Analysis reports show added/removed symbols, detailed changes in parameters and data types in the vmlinux binary and basic modules. I maintain this page, so feel free to ask me to check any particular kernel versions.

Kernel module compatibility with kernel recompiled with new patch

"Is it possible to compile a kernel once and have it be compatible with all 4.14 kernels?"
If security updates and backports do not break anything, maybe.
However there is no stable Kernel API/ABI in the Kernel.
Just userland API/ABIs are stable.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Stable-API-ABI
https://github.com/torvalds/linux/blob/master/Documentation/process/stable-api-nonsense.rst

Here a post to automatically check, if any API/ABI to userland will break/breaks:
Linux kernel API changes/additions

For Kernel ABI I found a tool for that (and your use case):
https://developers.redhat.com/blog/2018/03/28/analyzing-binary-interface-changes-linux-kernel/

how to write cross-version/platform Linux kernel modules?

Linux, the ying and the yang. Tangrs answer is good; it answers your question. However, there is the linux compat projects. See the backports wiki. Basically, there are libraries that provide shim functionality for newer Linux ABI's which you can use to link your code. The KERNEL_VERSION macro that Eugene notes is inspected in a compat.h, and appropriate compat-2.6.38.h, etc are included where each version has either macros and/or library functions to provide a forward API.

This lets the Linux Wifi group write code for the bleeding edge kernel, while still making it possible to compile on older kernel versions.

I guess this answers the question,

if there are any standard ways to deal with versioning?

The compat library is not a panacea, but at least it is there and under development.

Open source - There are many mutations. They all have a different plan.

linux kernel:why not put device as the first member of platform_device struct

Portability mostly. You don't control the struct definition and it might change in a subsequent version of the linux kernel. And if you depend on the dev being first then the device will suddenly break on an updated version of the kernel.

The container_of is a constant expression, thus it gets calculated at compile time and there's no overhead to this.

Branching & Merging strategy - Linux kernel

Page 123 of ProGit tells me that the Linux Kernel uses the "Dictator and Lieutenants Workflow" (Section Distributed Workflows in ProGit)

This way the verification of the commits is splitted into different stages and each blob is reviewed multiple times I assume. Since I am no Linux Kernel developer myself, I do not know the guidelines how the commits should be tagged.

---

Related Topics