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.
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/
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).
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.
Is it possible to upgrade only a specific sub-system, say I2C, of the Linux Kernel.
For example:
Is it possible to include "Support for multiplexed I2C bus topologies (introduced in Kernel 2.6.36)" in the Kernel version 2.6.31.1.
No this is not possible.
A kernel module or 'subsystem' (eg the i2c module) is build for a specific kernel image, you cannot combine different kernel(module) versions.
If you are feeling lucky (depending on your kernel skills), you could:
download the source code of your kernel
Install compiler and friends
add the updated ic2 driver
Try to compile the module for your kernel version
Cross your fingers and load it into your own kernel...\
I do not have any experience with this, so I do not know whether this works or not. Of course, if the ic2 module requires other (updated) modules, you could be ending up with updating (almost) the complete kernel...