When we run make on command line only the first target

(Label or Argument) is executed, remaining are not, to execute

the other targets we have to use make along with label name. In
the previous example we have three labels all, install and clean.
The label all will be automatically executed by make as it is the
first target to execute the other targets we must initiate them
using
make <target>
Ex:- make install //to use the target install
make clean //to use the target clean
The purpose of install is to make an out-of-tree module an
in-tree module. When we say make install whichever out-oftree modules .kos that are created will be copied into
lib/modules/<ker ver>/build/extra. Make clean will
remove all the intermediary files generated. i.e. it will remove .o
and .ko files generated in the current directory.
If we dont mention any thing and simply use make the
default is always first one. The first target, irrespective of we give
the label or not. Default execution always is defined.
Programming Kernel Modules:Modules are special object
dynamically extend kernel services.

files

which

are

used

to

While implementing source code for a kernel module

following issues are to be considered.
None of the APIs of the user space are not used for module.
Source should not contain calls to user mode functions
(including APIs), standard C Library.
Module sources must include kernel headers only.
/lib/modules/<version>/build/include

It is good programming practice to include following kernel

headers in every module.
#include<linux/init.h>
#include<linux/module.h>
#include<linux/kernel.h>
#include<linux/version.h>
Link-loader is the shared object manager. It is responsible
to bind, un-bind shared object with an application.
Similar to Link Loader kernel also has a sub-system called
Kmod. This module.h header file is to interact with that subsystem. If at all the module wants to configure some of the
attributes, it needs to interact with the Kmod. To interact with
Kmod there are some MACROs and Functions, which are called
Kmod interfaces. In case we want to use those MACROs and
Functions then they must be verified for that we use module.h.
Module.h contains interfaces for Kmod. Kmod interface
contains the signatures of the routines and MACROs through
which we can talk to Kmod.
Init.h
MACROs.

contains

interfaces

for

initialization

sequence

Any binary file that loads must have a constructor and

destructor.
Module will have one function called init_module () as a
constructor, cleanup_module () as a destructor. Initialization
and exit routines.
In shared object also we may implement them or not
implement them, they are optional. If we dont implement default
are provided which are empty files.
These are always optional if we want we can over write them
by default. The init_module routine is run when the module is
deployed. When it is about to get binded with the kernel process
address space or kernel address space. Exit will run when the
module is to be detached.

Init_module function will have a signature

int init_module(void);
The cleanup_module will have a signature
void cleanup_module(void);
If we skip them empty functions will be added by default.
Module source can contain initialization and Exit routines.
#include<linux/module.h>
#include<linux/init.h>
#include<linux/kernel.h>
#include<linux/version.h>
int init_module(void)
{
printk("%s : Module inserted\n",__func__);
return 0;
}

Initialization routine of
a module

void cleanup_module(void)
{
printk("%s : Module Detached\n",__func__);
}

Exit routine of a
module

We cannot use printf as it is user library, alternative to

printf in kernel space is printk.
Init routine is executed when module is deployed (Loaded).
Exit function is executed when the module is unloaded.
Init function of the module is run in the context of insmod
(Assuming insmod is used to load the module).
Insmod uses a kernel API init_module which loads module
image into kernel address space and executes init function of the
module.
Modules are unloaded using delete_module system call.
The purpose of comments is readability (we want to make it
easy for anyone looking at our code.). Some comments will be
describing our syntax. Some are not describing our syntax.

There are basically two categories of commenting, one

category is called code information commenting, code information
means which project, which module, who is the owner of that
module, modification lock, which license it is under, and so on.
Rest of the comments which are used for code description are
called code description modules.
When the program is converted to binary file all the
comments are removed.
In case of open-source community we must find some way to
add some essential comments to binary files, because the owners
of the modules may distribute the binary files to clients. From
within the binary file they should be able to pull out some
information about, who is the owner, which license, when was it
written some information which license and all that. Here, we
need at least the few comments to go into binary file. Those
Macros we see below are a method of that. Those Macros are
nothing but whichever comments we think the user should have
access to, those comments we pass arguments to MACROs.
Kmod will give us those Macros, pass those Macros and retain
those comments into binary file. This particular header file called
module.h of Kmod provides us a set of comment Macros.
Using them is purely optional, using MODULE_LICENSE is
mandatory for every module we write.
We must declare at least one License.
There are two category of licenses one category is called
copyright, and the other is called copy left.
Most of the closed copy of licenses are called copyrights.
Proprietary licenses are copy rights. User only gets the binary file
if user has any problem with the binary file, he has to go to the
main author from where he has got. This is known as vendor
locking.
In the open source code the license is called a copy left. The
user will have access to binary as well as source code. The reason
why source is given is to complete the ownership part. The user

now can go to anyone who understands the source for help, need
not go to only that particular author. Free term in open source
community means freedom to access of source.
Module can be either copy left or copyright, if I specify
proprietary the license will become copyright. Specifying Module
license is mandatory, default is proprietary and Linux will throw
a warning module license not specified.
Modules can use appropriate commenting MACROs to retain
essential code information and description into binary file.
Module.h provides various macros for this.
For Ex.:

MODULE_AUTHOR (<author name>);

MODULE_DESCRIPTION
(<Description

of

Module>);
MODULE_LICENSE (<license>);
Modules can be composed of various data and functions.
Module is the means of loading something into kernel.
Module itself is not a driver. A body of module can be a driver.
Body of a module can be a file system. What we are trying to add
to kernel is the body of a module. Module is the means of loading
a service dynamically. The service is then referred to as body of a
module. Its the carrier through which we are loading some pay
load (Service). This part of the code will repeat in every module
only body will change depending on what we are trying to do.
Module is not a process its a carrier, it is a method to wrap some
code and carry into kernel space. In the below example body is a
func ().
#include<linux/module.h>
#include<linux/init.h>
#include<linux/kernel.h>
#include<linux/version.h>
void func(void)
{
printk("%s : Body of the Module\n",__func__);
}

Body of the module

int init_module(void)
{
printk("%s : Module inserted\n",__func__);
return 0;
}

Initialization routine of
a module

void cleanup_module(void)
{
printk("%s : Module Detached\n",__func__);
}

Exit routine of a
module

Normal, GCC creates a normal Relocatable, this is the reason

why we use the build script, it creates a customized Relocatable,
and ELF format internally is modified to suite the module
deployment. Though it shows relocatable it is not equivalent to
.o file. Thats reason build script is mandatory.
End user if he has a .ko he can retrieve those comments
using a tool called modinfo. Modinfo will show all the details
about the module. Modinfo we have to use on .ko file. It also
gives us which kernel version this module was build for.

This module can be used only on this kernel. Even if the

release version is different we cant use this kernel. Module once
build is specific to kernel. Modules are not portable.
This is for testing purpose only.
One of the methods to load a module is called insmod. Use
insmod and mention module name it will deploy the module into
kernel address space.
# insmod <module_name>

If it is successful prompt will return. Otherwise, insmod fails

deploying it, immediately, it will show us appropriate error code.
This we must do as a root user, sudo is mandatory for this. Only
administrators can load a module.
lsmod is a tool that will show us list of modules that are
currently loaded. If our module is loaded successfully it must be
displayed in the list of modules currently shown by lsmod.

First one is always the latest module deployed. The others

are loaded by the kernel at the boot time. For testing we are
dynamically loading module. If we create an in-tree module and
build a kernel it will get loaded automatically by the kernel at boot
time.
Same can be verified using cat /proc/modules. Both
lsmod and this are same

The init function is run when module is deployed. We can

use the tool called dmesg to print the messages that are in the
kernel buffer. Init function has already executed if the message
appears in dmesg thats the confirmation.
Kernel print statements will not be shown on console. We
must use a tool to print that printks. dmesg is the tool to print
this messages.
Use dmesg C to clear all the previous messages.
The exit function cleanup_module is run when we unload
the module.
In memory there is only image. We must use the tool
rmmod to unload module from the Linux kernel.
When we add a module it gets added to kernels code
segment. When we say detach it will get removed from kernels
code segment.
We can use strace to view all the system calls taken to run
this file.
Init module loads ELF into kernel space and runs the
modules init function.
Init function of the module will run in the context of insmod.
Init function until completed insmod will not come to user
mode. Insmod is going into kernel mode, loading our module.
insmod will fail if we return -1 from init_module (). If we return
0 in init_module () then, insmod will commit the module and then
return. It means init_module function after it is executed then it is
committed, whether to commit the module or abort it. If init
function is 0 module is committed to process address space. If init
function return negative number module is aborted. Return value
of insmod is nothing but return value of init_module ().
Why is it designed like this?
May be we are trying to load a driver, before loading a driver
we want to check if device is there. Where to write that code
now? Init_module (). Init function we write a code to detect the

device is present or not, if it is present we will commit, else we

will abort. It will give us flexibility to do lot of conditional checking
before we commit our resource.
If we dont want init_module () and cleanup_module ()
names as function names we can change them as we wish but we
must tell the kmod that this is my init_module () and this is my
cleanup_module () in the following manner:
module_init(myinit);
module_exit(myexit);