5

I'm new to programming Linux kernel modules, and many getting started guides on the topic include little information about how to build a kernel module which will run on many versions and CPU platforms of Linux. Most of the guides I've seen simply state things like, "Linux doesn't ensure any ABI/API compatibility between versions." However, other OSes do provide these guarantees for major versions, and the guides are mostly targeting 2.7 (which is a bit old now).

I was wondering if there is any kind of ABI/API compatibility now, or if there are any standard ways to deal with versioning other than isolating the kernel-dependent bits of my code into files with a ton of preprocessor directives. (Also, are there any standard preprocessor symbols I should be using in the second case?)

linuxbuild
  • 15,843
  • 6
  • 60
  • 87
Dan
  • 7,155
  • 2
  • 29
  • 54
  • 1
    Among other things, `LINUX_VERSION_CODE` and `KERNEL_VERSION(major, minor, micro)` macros are often used in such code to check the kernel version. Like this, for example: `#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 7, 0) ...` – Eugene Jun 17 '13 at 19:15
  • 2
    You can also take a look at a notable example of the kernel modules that are currently not in the upstream kernel: VirtualBox Guest Additions. See, for instance, the implementation of `sf_lookup()` in [dirops.c](https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux/sharedfolders/dirops.c). It is probably not an ideal way to handle the changing kernel API but still may give you some hints. – Eugene Jun 17 '13 at 19:21

2 Answers2

9

There isn't a stable ABI for the kernel and most likely never will be because it'd make Linux suck. The reasons for not having one are all pretty much documented in that link.

The best way to deal with this is to get your driver merged upstream where it'll be maintained by other kernel developers.

As to being cross-platform, that pretty much comes free with the Linux kernel as long as you only use the standard, platform-independent functions provided in the API.

tangrs
  • 9,709
  • 1
  • 38
  • 53
  • 1
    @Dan, I agree with tangrs. One thing I would like to add is that getting a driver merged to the upstream kernel may take a while. Until then, I'd better stick to APIs that many of upstream kernel modules use. Even is those APIs do change in a new kernel version, you would be able to look at these kernel modules and make similar changes to your own ones to adapt to the new APIs. You can take a look at [Linux Cross Reference](http://lxr.free-electrons.com/ident) to find which modules are using the functions you plan to use. – Eugene Jun 17 '13 at 19:13
4

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.

Community
  • 1
  • 1
artless noise
  • 21,212
  • 6
  • 68
  • 105
  • Aha! I suspected the sole key to Linux's success wasn't the fact that it has no ABI compatibility across versions... :) – Dan Jun 18 '13 at 07:59