I have a simple question about modules in the linux kernel.
Is it guaranteed that my compiled module works throughout the whole X.Y kernel release.
X: Kernel version
Y: Major version
Z: Minor version
So for example:
I compile my module.ko with the tree of a 4.9 Kernel.
Then it is possible to insmod my module with 4.9.24, 4.9.31,4.9.34,...?
So does the vermagic comparison skip everything after the major number?
Are you familiar with https://github.com/torvalds/linux/blob/master/Documentation/process/stable-api-nonsense.rst ?
If you want stable ABI you need to target kernels shipped with RHEL or SLES (or their derivatives which claim to maintain the ABI).
Related
I would like to know if a Linux Kernel Module can be used with a Linux Kernel version of a higher patch number (last number in the version) than the kernel was compiled against.
Take the following example:
You are currently using Linux 4.14.75 for an ARM target
I give you an RPM containing an application and kernel module that work together. The module was compiled against the 4.14.75 kernel. The module is loaded with insmod by the application.
A security concern arises and you update your target's kernel to 4.14.100.
Given this situation, will the kernel module in the RPM I gave you work with the new kernel?Is it possible to compile a kernel once and have it be compatible with all 4.14 kernels?
I am NOT asking if depmod/modprobe will work or if it is good practice.
"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/
Is there an equivalent to the i2c_adapter_quirks struct in kernel 3.18? I am trying to implement an i2c bus driver that has a maximum read and write length.
There's no equivalent. i2c_adapter_quirks was introduced in version 4.1 of the kernel; the patches are very clean so it should be possible to backport the patch series, starting with 2187f03a9576 and b7f625840267.
Well, let's start with what I know.
I know that I can apply a linux kernel patch to upgrade my current kernel version. let's say that I've a 4.2 version and I want to upgrade to 4.3 I can apply this patch:
https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.3.xz
Now let's say that I don't want that I want to install the 4.3 kernel(without patching my current one) I can do that by:
https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.3.tar.xz
Now let's move on to what ruined my knowledge, while researching on how to make a linux kernel run in RealTime, I found that I need to apply this patch to the kernel that I downloaded:
https://www.kernel.org/pub/linux/kernel/projects/rt/4.1/patch-4.1.15-rt17.patch.xz
My question here is: Does "linux-4.3.tar.xz" have RT support on no, to have it available I need to apply "patch-4.1.15-rt17.patch.xz" to any kernel that I want to be supporting RealTime feature ?
some Src: http://proaudio.tuxfamily.org/wiki/index.php?title=Realtime_(RT)_Kernel#Obtain_the_kernel-source_and_necessary_patches
New kernel contains only accepted patches. AFAIK RT kernel patches are not accepted in vanilla kernel (to which you refer as "patch-4.3"), so it is developed as separate project and provides its own patches to be applied on vanilla kernel.
I suppose RT support is developed in this repository: https://git.kernel.org/cgit/linux/kernel/git/rt/linux-rt-devel.git/
Here is a repository for vanilla kernel: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/
You may try to seek any merges from RT to vanilla kernel, but I doubt that they exist.
The RT patches are not part of the upstream, mainline kernel yet. It's a feature in development, and released as patches on top of each supported mainline kernel release. To use RT, you need to choose the RT patchset that matches the mainline kernel you want to use.
Gradually, the patches are being merged to mainline kernel. At the same time, the mainline kernel moves on, and the other out-of-tree RT patches might no longer apply without rebasing. That's why there are RT patches for each (supported) mainline kernel release.
I need to add a wireless driver to a Yocto image that uses kernel 3.10.17. My problem is that the driver entered mainline kernel since version 3.11 (and it is also part of the backports project). I have read the Yocto documentation about kernel development, but it more confused me. What is the proper way to accomplish this? (I suppose adding the driver sources by hand is not).
First: It's not clear which Yocto version you are using. So you might want to update to the current 1.7 version (Dizzy) which provides Kernel 3.10, 3.14 and 3.17.
You can find the kernel configuration in meta/recipes-kernel/linux. Be aware that a BSP or any other layer can also provide other kernel versions/configuration as well as limiting accepted/working version (especially if you use a BSP).
That said, you can define the kernel version that should be used by adding/adjusting PREFERRED_VERSION. An example is PREFERRED_VERSION_linux-stable = "3.10". Another one you can find is PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev".
Please be aware that just choosing another kernel doesn't guarantee that the kernel module you want to have will be automatically build. You might need to adjust the kernel configuration to compile it into the kernel or build it as module.
how can I obtain runtime information about which version of kernel is running from inside linux kernel module code (kernel mode)?
By convention, Linux kernel module loading mechanism doesn't allow loading modules that were not compiled against the running kernel, so the "running kernel" you are referring to is most likely is already known at kernel module compilation time.
For retrieving the version string constant, older versions require you to include <linux/version.h>, others <linux/utsrelease.h>, and newer ones <generated/utsrelease.h>. If you really want to get more information at run-time, then utsname() function from linux/utsname.h is the most standard run-time interface.
The implementation of the virtual /proc/version procfs node uses utsname()->release.
If you want to condition the code based on kernel version in compile time, you can use a preprocessor block such as:
#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,16)
...
#else
...
#endif
It allows you to compare against major/minor versions.
You can only safely build a module for any one kernel version at a time. This means that asking from a module at runtime is redundant.
You can find this out at build time, by looking at the value of UTS_RELEASE in recent kernels this is in <generated/utsrelease.h> amongst other ways of doing this.
Why can't I build a kernel module for any version?
Because the kernel module API is unstable by design as explained in the kernel tree at: Documentation/stable_api_nonsense.txt. The summary reads:
Executive Summary
-----------------
You think you want a stable kernel interface, but you really do not, and
you don't even know it. What you want is a stable running driver, and
you get that only if your driver is in the main kernel tree. You also
get lots of other good benefits if your driver is in the main kernel
tree, all of which has made Linux into such a strong, stable, and mature
operating system which is the reason you are using it in the first
place.
See also: How to build a Linux kernel module so that it is compatible with all kernel releases?
How to do it at compile time was asked at: Is there a macro definition to check the Linux kernel version?