A quick and easy intro to writing device drivers for Linux.

What is a Device Driver?

Device driver is software which gives a device its behavior. A device driver often called a driver for short, is a computer program that enables another program typically an operating system (OS) (e.g., Windows, Linux, FreeBSD) to interact with a hardware device.

Device Drivers can be classified into

Statically linked driver

Where object code is linked with the kernel. The code of the device driver is physically contained in the kernel and therefore loaded in memory when system boots.

Dynamically linked driver

Whose object code is not linked with the kernel. The code of such device driver is not contained in the kernel, and the device driver is loaded and unloaded as and when required.
By compiling the driver into an object format that the kernel can load whenever access to specific device is required. Kernel code that can be automatically loaded into kernel is known as loadable kernel module.

Writing a kernel module

Writing your own module lets you write some standalone kernel code, learn how to use modules, and discover a few rules about how the kernel links together.
Note: These instructions were written for the 2.6.x kernels and may not work with different kernel versions.

Does your kernel support modules?

For this lesson, your kernel must have been compiled with these options:

Loadable module support —>

[*] Enable loadable module support
[*] Module unloading
[ ] Module versioning support (EXPERIMENTAL)
[*] Automatic kernel module loading

If you compiled your kernel according to the instructions in the first few kernel lessons, you should already have these options properly set. Otherwise, change these options, recompile the kernel, and boot into your new kernel.

The below code shows a simple “hello world” module, copy and paste the following code into a file named mymodule.c

#include <linux/init.h>
#include <linux/module.h>

#define DRIVER_DESCRIPTION "Hello world, test driver"

static int __init hello_init (void)
 printk (KERN_ALERT "Hello world\n");
 return 0;

static void __exit hello_exit (void)
 printk (KERN_ALERT "Goodbye\n");

/* hello_init is the initialization function. */
module_init (hello_init);
/* hello_exit is the exit function. */
module_exit (hello_exit);


Save the file and edit the Makefile in the same directory.

obj-m += mymodule.o

 make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

 make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
 rm -f *~

Compile your module:

# make

Load the module. Depending on your kernel version, do that with either:

# insmod ./mymodule.o


# insmod ./mymodule.ko

And check to see if your message printed out:

# dmesg | tail

You should see this at the end of the output:

Hello world

Now remove the kernel module:

# rmmod mymodule

Check the output of dmesg again, you should see:


You just wrote and ran a new kernel module! Congratulations!

The module/kernel interface

Now, let’s do some more interesting things with your module. One of the key things to realize is that modules can only “see” functions and variables that the kernel deliberately makes visible to the modules. First, let’s try to do things the wrong way.

First, find the source that your current Linux kernel was compiled from. Edit the file kernel/printk.c and add this line after all the included files and near the other global variable declarations (but outside all functions):

int my_variable = 0;

Now recompile your kernel and reboot into your new kernel. Next, add this to the beginning of your module’s mymodule_init function, before the other code:

extern int my_variable;
 printk ("my_variable is %d\n", my_variable);

Save your changes and recompile your module:

# make

And load the module (this will fail):

# insmod ./mymodule.ko

Loading your module should fail with the message:

insmod: error inserting './mymodule.ko': -1 Unknown symbol in module

What this is saying is that the kernel is not allowing modules to see that variable. When the module loads, it has to resolve all it’s external references, like function names or variable names. If it can’t find all of it’s unresolved names in the list of symbols that the kernel exports, then the module can’t write to that variable or call that function. The variable my_variable has space allocated for it somewhere in the kernel, but the module can’t figure out where.
To fix this, we’re going to add my_variable to the list of symbols that the kernel exports. Many kernel directories have a file specifically for exporting symbols defined in that directory. Bring up the file kernel/printk.c again and add this line after the declaration of your variable:


Recompile and reboot into your new kernel. Now try to load your module again:

# insmod ./mymodule.ko

This time, when you check dmesg, you should see:

my_variable is 0
Hello world

Reload your module:

# rmmod mymodule && insmod ./mymodule.ko

Now you should see:

my_variable is 1
Hello world

Each time you reload the module, my_variable should increase by one. You are reading and writing to a variable which is defined in the main kernel. Your module can access any variable or function in the main kernel, as long as it is explicitly exported via the EXPORT_SYMBOL() declaration. For example, the function printk() is defined in the kernel and exported in the file kernel/printk.c.

A simple loadable kernel module is a fun way to explore the kernel. For example, you can use a module to turn a printk on or off, by defining a variable do_print in the kernel which is initially set to 0. Then make all your printk’s dependent on “do_print”:

if (do_print)
 printk ("Big long obnoxious message\n");

And turn on do_print only when your module is loaded. You can add a function defined in your module to the list of functions that are called when the kernel receives a certain interrupt (use cat /proc/interrupts to find out what interrupts are in use). The function request_irq() adds your function to the list of handlers for a selected irq line, which you can use to print out a message each time you receive an interrupt on that line. You can investigate the current value of any exported variable by loading a module that reads that value and immediately exits (returns a non-zero value from the module_init() function). The variable jiffies, which increments every 1/100th of a second (on most platforms), is a good candidate for this kind of module.

Play with your new kernel module – modules are fun!