Showing posts with label kernel. Show all posts
Showing posts with label kernel. Show all posts
Monday, March 9, 2015
What is a Kernel Module
Modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system.
Example: one type of module is the device driver, which allows the kernel to access hardware connected to the system.
Without modules, we would have to build monolithic kernels and add new functionality directly into the kernel image. Besides having larger kernels, this has the disadvantage of requiring us to rebuild and reboot the kernel every time we want new functionality.
Note: Copying the code directly into your source.c file will also copies the invisible characters and finally you will left out with stray errors, i recommend you to type the code and that even becomes a practice.
Click here: Difference between monolithic kernel and micro kernel.
- kernel modules are object files that contain kernel code.
- They can be loaded and removed from the kernel during run time.
- They contain unresolved symbols that are linked into the kernel when the module is loaded.
- kernel modules can only do some of the things that built-in code can do , they do not have access to internal kernel symbols.dep
Kernel Module Utilities:
lsmod : lists the modules already loaded into kernel.
rmmod : Removes or unloads a module one at a time.
insmod : Insert or load a module.
depmod : Creates the data base of module dependencies. This is created based on the information present in /lib/modules/module.dep file.
modprob : Inserts a module and its dependencies based on information from modules.dep file.
modinfo : List the information about the module like author, version tag, parameters etc.
Writing a simple kernel module:
Here I am explaining how to write a simple kernel module that doesnt have any functionality.
Every Kernel modules must have at least two functions:
"start" (initialization) function called init_module()
It is called when the module is loaded using insmod into the kernel.
"end" (cleanup) function called cleanup_module()
It is called just before it is removed using rmmod.
Code for test.c:Writing a simple kernel module:
Here I am explaining how to write a simple kernel module that doesnt have any functionality.
Every Kernel modules must have at least two functions:
"start" (initialization) function called init_module()
It is called when the module is loaded using insmod into the kernel.
"end" (cleanup) function called cleanup_module()
It is called just before it is removed using rmmod.
Kmod is a subsystem that allows the loading and unloading of modules.
Issues to be considered in writing a kernel module:
- Module code should not invoke user space Libraries or API’s or System calls.
- Modules are free to use kernel data types and GNU-C extensions for linux kernel.
- Following path contains the list of header files that can be included in module programs./lib/modules/2.6.32.generic/build/include/linux.
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/version.h>
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("This is a my First Test Module...!");
MODULE_AUTHOR("GVK51");
int init_module(void){
printk(KERN_INFO "My first Test module loaded...!
");
return 0;
}
void cleanup_module(void){
printk(KERN_INFO "My first Test module Un-loaded...!
");
}
Note: Copying the code directly into your source.c file will also copies the invisible characters and finally you will left out with stray errors, i recommend you to type the code and that even becomes a practice.
module.h : module management subsystem, its an interface file for Kmod functions.
kernel.h : resolves kernel symbol calls, it provides access to global symbol table.
init.h : describes the sequence of initialization.
version.h : It binds a module to a particular version of kernel.
printk : printk is printf for kernel programs, as said earlier modules can’t use stdlib due to user space/ kernel space issues. Most of C library is implemented in kernel. with in printk “KERN_INFO” is a macro found in kernel.h that defines the priority to printk logs. There are 8 such macros as shown below.
0- highest priority 7-lowest priority
KERN_EMERG "<0>" /* system is unusable */
KERN_ALERT "<1>" /* action must be taken immediately */
KERN_CRIT "<2>" /* critical conditions */
KERN_ERR "<3>" /* error conditions */
KERN_WARNING "<4>" /* warning conditions */
KERN_NOTICE "<5>" /* normal but significant condition */
KERN_INFO "<6>" /* informational */
KERN_DEBUG "<7>" /* debug-level messages */
MACROS :
MODULE_LICENSE() : declares the modules licensing
MODULE_DESCRIPTION() : to describe what the module does
MODULE_AUTHOR() : declares the modules author
- In modules the comments are achieved with macros so that information of module sits along with the code so that debugging becomes easy. i.e., comments are not stripped out.
- License macro is mandatory even if it is free or proprietary.
- Modules can comprise of any number of functions and data elements which form module body.
Building a Module:
Kernel source has two types of make files:
- src/Makefile called as top/primary Makefile
- Each branch in kernel source has a Makefile called as kbuild Makefile.
So to build a module we have to write a Makefile that follows the rules followed by kbuild. To learn more on how to compile modules, see file linux/Documentation/kbuild/modules.txt.
Makefile:
obj-m := test.o
all:
make -C /lib/modules/$(shell uname -r)/build/ M=$(shell pwd) modules
clear:
make -C /lib/modules/$(shell uname -r)/build/ M=$(shell pwd) clean
from a technical point of view the first line is really necessary, the "all" and "clean" targets were added for convenience, and make sure that after "all:" give a tab and write the command as its a convention in writing Makefile.
Now you can compile the module test.c using make command. Here is the list of command I am executing the corresponding output is show in below image highlighted with blue arrow.
Note: You should be the root user or should have requisite permissions to load and unload modules.
$ ls (to list the files in the current directory)
$ make ( to build the module, this will generate many files)
$ ls (to list the files in the current directory)
$ insmod test.ko ( loading the module)
$ dmesg ( to see the messages printed by printk)
$ modinfo test.ko (this display the module informatio, we have put in macros)
$ rmmod test ( unloading the module)
$ dmesg ( to see the messages printed by printk)
Wednesday, March 4, 2015
How To Build Linux Kernel
Here we compile kernel source to generate a new kernel image and this new image is used at the next boot of the system.
(Mainline kernel is called as vanilla kernel)
Note: I am assuming that you, as a root user in source directory, at /usr/lib/linux-2.6.32 (linux-2.6.32 name of the kernel source directory that we obtained after unzipping). It’s a convention to place the unzipped source directory at /usr/lib but it can be any where, but to build you have to be in the source directory.
Step1: Assign kernel version tag.
To do so open the Makefile in the source directory at the path /usr/lib/linux-2.6.32/Makefile and at the top of the file you will find the field EXTRAVERSION, edit as follows
$ Vim Makefile
Modify: EXTRAVERSION = .firstbuild
*save the above changes to file.
Step2: Choose kernel configuration.
To do so type that following command. This will generate a configuration file “.config”. Any file that starts with “.” is a hidden file, to list the hidden files use option a with ls command.
$ make menuconfig (this pumps kernel info onto console, wait until prompt returns)
Because the Linux source code is available, it follows that you can configure and custom tailor it before compiling. Indeed, it is possible to compile support into your kernel for only the specific features and drivers you want. Configuring the kernel is a required step before building it. Kernel provides multiple tools to facilitate configuration. The simplest tool is a text-based command-line utility.
$ make config
This utility goes through each option, one by one, and asks the user to interactively select yes, no, or (for tristates) module. Because this takes a long time, unless you are paid by the hour, you should use an ncurses-based graphical utility.
$ make menuconfig
To make very simple use oldconfig option.
$ make oldconfig
Ultimately they generate .config file.
Note: refer to man pages on make, type “make help” at your terminal.
Step3: Compile the source to create kernel image (raw) and modules.
$ make
This takes around 30 min on a normal desktop, to speed up, create threads if yours is a multicore machine. To build the kernel with multiple makes jobs, use
$ make -jn
Here, n is the number of jobs to spawn. Usual practice is to spawn one or two jobs per processor.
Step4: Install the modules on file system.
To do so type the following command.
$ make modules_install
This copies the modules into disk space and adds folder at /lib/modules/[name].
Here name will be 2.6.32.firstbuild
Step5:
As an example, on an x86 system using grub, you would copy arch/i386/boot/bzImage
to /boot, name it something like vmlinuz-version
$ cp arch/x86/boot/bzImage /boot/vmlinuz-2.6.32.firstbuild
Step6:
The build process also creates the file System.map in the root of the kernel source tree. It contains a symbol lookup table, mapping kernel symbols to their start addresses. copy System.map to /boot, name it something like System.map-version
$cp System.map /boot/System.map-2.6.32.firstbuild
$mkinitramfs –o /boot/initrd.img-2.6.32.firstbuild 2.6.32.firstbuild
here 2.6.32.firstbuild is the name of folder that was automatically created at /lib/modules
Step7: Update Grub
$ update-grub
If you open the file grub.cfg at the path /boot/grub/grub.cfg the ###BEGIN/etc/grub.d/10_linux ### segment should look like this
$ gedit /boot/grub/grub.cfg
### BEGIN /etc/grub.d/10_linux ###
menuentry Ubuntu, with Linux 2.6.32.firstbuild --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root=(hd0,1)
search --no-floppy --fs-uuid --set f57b34e4-1bf6-4135-993f-3db8881340d0
linux /boot/vmlinuz-2.6.32.firstbuild root=UUID=f57b34e4-1bf6-4135-993f-3db8881340d0 ro quiet splash
initrd /boot/initrd.img-2.6.32.firstbuild
}
menuentry Ubuntu, with Linux 2.6.32.firstbuild (recovery mode) --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root=(hd0,1)
search --no-floppy --fs-uuid --set f57b34e4-1bf6-4135-993f-3db8881340d0
echo Loading Linux 2.6.32.firstbuild ...
linux /boot/vmlinuz-2.6.32.firstbuild root=UUID=f57b34e4-1bf6-4135-993f-3db8881340d0 ro single
echo Loading initial ramdisk ...
initrd /boot/initrd.img-2.6.32.firstbuild
}
Note1: In "/boot/grub/grub.cfg" you will find fields like "timeout = -1" Change it to "timeout = 10", so that even if your new image crashes you have chance to select the generic image in the next Restart.
Note2: If the ###BEGIN/etc/grub.d/10_linux ### segment doesn’t start with your new image then you manually cut and paste the above two blocks of code from this segment and paste it below ###BEGIN as very first line.
Restart your system.
Note3: Make sure that while executing Step4 all the modules are copied, if this process stops with few modules copied, like less than a count of 10, then its clear that build was not complete, this can be a reason that you were not as root user while building the kernel and even if the error still persists, chmod 777 kernel-source/* directory. and start all the above steps.
Note4: If you encounter kernel-panic after you restart with grub updated with new kernel configuration then above Note3 can be a solution or else the source is not downloaded completely.
Note3: Make sure that while executing Step4 all the modules are copied, if this process stops with few modules copied, like less than a count of 10, then its clear that build was not complete, this can be a reason that you were not as root user while building the kernel and even if the error still persists, chmod 777 kernel-source/* directory. and start all the above steps.
Note4: If you encounter kernel-panic after you restart with grub updated with new kernel configuration then above Note3 can be a solution or else the source is not downloaded completely.
The above process can be simple given as :
First you should be the root user and then go to source folder and then edit the Makefile “EXTRAVERSION” filed in source directory to “.firstbuild”, and execute these commands in sequence. Make sure that you are in root.
$ make oldconfig
$ make
$ make modules_install
$ cp arch/x86/boot/bzImage /boot/vmlinuz-2.6.32.firstbuild
$ cp System.map /boot/System.map-2.6.32.firstbuild
$ mkinitramfs –o /boot/initrd.img-2.6.32.firstbuild 2.6.32.firstbuild
$ update-grub
Tuesday, March 3, 2015
Microkernel VS Monolithic Kernel
This post explains the two main kernel architectures of operating systems: the monolithic kernel and the micro kernel. Starting with an introduction about the term ”kernel” itself and its meaning for operating systems as a whole, it continues with a comparison of benefits and disadvantages of both architectures.


Research in the field of μ-kernels prove, that it is not the best solution to create a hybrid kernel 1 , but a pure micro kernel, which has to be very small in size. So small, that it fits into the processor’s first level cache as a whole. Second generation μ-kernels like the L4 are highly optimized, not just referring to the processor family, but also to the processor itself 2 , which results in a very good I/O performance.
Kernel: kernel is the indispensable and therefore most important part of an operating system. Roughly, an operating system itself consists of two parts: the kernel space (privileged mode) and the user space (unprivileged mode). Without that, protection between the processes would be impossible.
There are two different concepts of kernels:
· monolithic kernel.
· μ-kernel (microkernel).
Monolithic kernel: The older approach is the monolithic kernel, of which Unix, MS-DOS and the early Mac OS are typical representants of. It runs every basic system service like process and memory management, interrupt handling and I/O communication, file system, etc. in kernel space see Figure 1 (click here for Anatomy of Linux Kernel). It is constructed in a layered fashion, built up from the fundamental process management up to the interfaces to the rest of the operating system (libraries and on top of them the applications). The inclusion of all basic services in kernel space has three big drawbacks.
· The kernel size increase.
· Lack of extensibility.
· The bad maintainability.

Figure 1: Monolithic Kernel base Operating System.
Bug-fixing or the addition of new features means a recompilation of the whole kernel. This is time and resource consuming because the compilation of a new kernel can take several hours and a lot of memory. Every time someone adds a new feature or fixes a bug, it means recompilation of the whole
kernel. (click here: “ How to Compile Kernel Source”)
To overcome these limitations of extensibility and maintain-ability, the idea of μ-kernels appeared at the end of the 1980’s.
Microkernel: The concept (Figure 2) was to reduce the kernel to basic process communication and I/O control, and let the other system services reside in user space in form of normal processes (as so called servers). There is a server for managing memory issues, one server does process management, another one manages drivers, and so on. Because the servers do not run in kernel space anymore, so called ”con-text switches” are needed, to allow user processes to enter privileged mode (and to exit again). That way, the μ-kernel is not a block of system services anymore, but represents just several basic abstractions and primitives to control the communication between the processes and between a process and the underlying hardware. Because communication is not done in a direct way anymore, a message system is introduced, which allows independent communication and favors extensibility.

Figure 2: Micro Kernel base Operating System.
Currently, there are two different generations of μ-kernels. The first generation was a more or less a stripped-down monolithic kernel. Because of performance drawbacks concerning process communication, several system services like device drivers, communication stacks, etc. found their way back into kernel space. This resulted in an even bigger kernel than before, which was slower than its monolithic counterpart.
In a simple way we can say like this :
Monolithic Kernel (Macro Kernel): Kernel Image = (Kernel Core+Kernel Services). When system boots up entire services are loaded and resides in memory.
Example: Windows and Unix.
Micro kernel : Kernel Image = Kernel Core. Services are build in to special modules which can be loaded and unloaded as per need.
We have another type of kernel integration technique called
Modular, this is derived from best of micro and monolithic kernel) In
Modular kernel integration: Kernel Image = (Kernel core + IPC service modules +Memory module +Process Management module). All other modules are loadable kernel modules.
Example: Linux kernel
Subscribe to:
Comments (Atom)