I should add a line in the file linux/drivers/pci/quirks.c of the Linux Kernel. I never modified/compiled the Linux Kernel, what is the best way to do that? I need to compile the entire Kernel to add a single line? Or can I write only a patch to apply to the current Kernel? And what happens if a new kernel version will be released?
Related
I have an (old) embedded system for which I want to compile programs. I don't have the toolchain, so I want to create one.
The embedded system has an "ARM926EJ-S rev 5 (v5l)" CPU and "cat /proc/version" says that it runs "Linux version 2.6.20.7" with GCC 4.0.2.
I have heard that I have to include the kernel headers in the build process. I download the Linux kernel version 2.6.20 from kernel.org, extract all files and run "make headers_install ARCH=arm INSTALL_HDR_PATH=~/headers". Is this the correct way or do I need the header files of the specific kernel?
untar the kernel.
make mrproper
make ARCH=${arch} headers_check
e.g make ARCH=arm headers_check
make ARCH=${CLFS_ARCH} INSTALL_HDR_PATH=dest headers_install
This are the steps to get headers from kernel.
The purpose of kernel headers is -->C library and compiled programs needs to interact with the kernel
i.e for Available system calls and their numbers, Constant definitions, Data structures, etc.
Therefore, compiling the C library requires kernel headers, and many applications also require them.
do I need the header files of the specific kernel?
The kernel-to-userspace ABI is backward compatible
--> 1)Binaries generated with a toolchain using kernel headers older
than the running kernel will work without problem, but won't
be able to use the new system calls, data structures, etc.
-->2)Binaries generated with a toolchain using kernel headers newer
than the running kernel might work on if they don't use the
recent features, otherwise they will break.
--->3)Using the latest kernel headers is not necessary, unless access
to the new kernel features is needed
So in your case kernel version is "Linux version 2.6.20.7"
You can use kernel headers of Linux kernel version 2.6.20 or 2.6.21 from kernel.org.
does not create any problem in this case.
That should be fine if you're using the headers to build a libc
You should probably run make ARCH=arm headers_check beforehand too.
I use CentOS and it does not have support for L2TPv3 which was introduced in 2.6.35.
CentOS is at 2.6.32. How do I selectively patch just the L2TPv3 changes to my kernel?
Also, these are kernel modules. Would I need to run the modified kernel to be able to insmod these KOs?
Back porting features is a very non trivial task, not something that can easily be done casually. Thus, your best option is to look around whether somebody created the necessary patches for your kernel version.
Also, Linux kernel has no strict interface definitions when modules are concerned, thus it is very desirable that kernel and modules are compiled from the same source. Sometimes it is possible to successfully use "mismatched" modules with a given kernel, but rather frequently an attempt to do so results in various problems.
But if you will adventurous, try using modprobe -f. This will disable the module version checking and modprobe will try to squeeze the module in (even at a cost of crashing the system on spot).
I am new to bootloader and Linux kernel. I have been working on a project where we have to replace booting QNX kernel with Linux kernel .Our current bootloader code has a support for booting QNX kernel.It seems like bootloader also has support for booting Linux(NOT sure) and I need to know is it doing enough to boot Linux Kernel.
Below is what our Bootloader is doing.
Bootloader is calling start_kernel function which have two argument passed to it one is kernel entry point and second is pointer to boot line
1.Address 0X90000ULL which is type casted to boot_params structure.
2.Relocate initrd
3.Copy boot sector ,Set up data and commad line to final resting place
4.Initialize Linux GDT
5.Jump to Kernel entry point
6.Disable interrupt
7.Lunch_kernel()
Now in above code two tricky things which doubted support for Linux kernel booting.
The first thing is the way Jump to kernel entry point, normally I see jumping to kernel entry in uboot or Linux source is in assembly but in our bootloader it simply filing a structure .
struct
{
long Kery;
long kernel_code_segment;
}
jumpv;
void *jump_s;
jumpv.kery=first argument pass to start_kernel;
jumpv.kernel_code_segment=0x10;
jump_s=(void *)&jumpv;
Second thing is the Lunch_kernel() for which definition is not present at all in code base.
Now is above stuff enough to pass control to Linux image or what else I can add/modified to boot the Linux image in our current bootloader code.
We are on working X86 architecture.
Due to some reason we can't do hit and trial on our board until we are sure about things.
I download the kernel source, compile it and run the new kernel. I am making some change to kvm kernel module and testing it.
So this is what I do after making some change in the kernel source.
make M=arch/x86/kvm
After this I am able to successfully insert the kernel module.
By mistake I did make mrproper which cleans all the binaries and byproducts on a linux compile.
So, is there a way now to make my kernel module only and insert it into current booted kernel or should I compile the whole kernel again and replace the new vmlinuz with vmlinuz file in /boot.
I can do the second option but it takes time and is not the most intelligent way for this small problem.
If the kernel is currently running you can try running make cloneconfig. This should configure the kernel tree exactly like the running kernel.
The compiled module should then match your kernel.
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?