Tag: Linux

Lets try for a “hello world” Linux driver this time. Yeah, I know there are heck lot of tutorials dealing with the same but since I am trying it out myself, I would like to share the steps I followed and the experience I gained out of it.
Drivers, not just in Linux but in all Operating Systems, lie directly on top of hardware, abstracting the device specific operations. This reduces the dependency of Operating System on hardware and thereby it makes easy for an operating system to switch between different hardware.
Didn’t get that? Let me try that once more. Before that let me tell you one fact: devices are categorized into three sets in Linux (this one is specific to Linux and Unix):

1. Character Devices    – devices which read one byte at a time.
2. Block Devices        – devices which a block (usually 512 bytes) at a time.
3. Network Devices        – devices which enables transfer(to be specific, send and receive) of packets over network.

By categorizing devices, Linux expects driver of each category to expose a standard interface. Now what is the use of that? Suppose two devices dev1 and dev2 have its own specific driver driv1 and driv2. If both drivers has a common interface (functions through which it gives out its services), say both implemented f1() and f2() functions, then a program using driv1 one will call f1() and f2() to use the dev1. Suppose at one point of time the user wants to replace dev1 with dev2; since the driver driv2 too follows the standard and has implementation of f1() and f2(), there will be no change in the calling process and it need not be recompiled. Thereby we could isolate the changes to a very small section. This is a good programming practice even outside driver-programming.
In this post, we will try to write our first driver which can be used with Linux. Driver-programming is a little bit different from our usual programming. Program execution in our everyday programming starts in ‘main’ function but in driver-programming main function disappears. Lets see our hello-world without any further ado.

#include <linux/init.h>
#include <linux/module.h>
MODULE_LICENSE(“Dual BSD/GPL”);

static int hello_kernel_init(void)
{
    printk(KERN_ALERT “Hello Kernel, at your service..\n”);
    return 0;
}

static void hello_kernel_exit(void)
{
    printk( KERN_ALERT “Goodbye Kernel, I am no longer at your service..\n”);
}

module_init(hello_kernel_init);
module_exit(hello_kernel_exit);

Don’t worry about the weird function calls: printk. Hope you already got the idea about module_init and module_exit. Those are to register our functions (hello_kernel_init and hello_kernel_exit) as functions to be called at the time of module initialization and exit. Good question: “when does that happen”. A driver module is invoked as part of any software requesting for a hardware service. That request from application goes to operating system and o/s (short form for operating system) loads the driver module specific to that hardware to serve the application. Leave those topics for the time being, we will cover it in coming chapters. ‘printk’ is just a ditto of printf function in C language; the difference is it has an identifier -> KERN_ALERT at the starting of first argument which tells the kernel the priority of the message printed by that printk function. There are other similar identifiers like KERN_INFO, KERN_WARNING, etc . Driver-modules are not supposed to use any library functions other than those implemented in kernel. This is because we wont link our code with libraries at the time of compilation. Linking and loading is the job of kernel. So when kernel links our module, if it sees any reference to functions which it doesn’t implement, it will cause a failure of our code, if not an entire system failure at rare cases.
Forgot to tell you that my development environment is Ubuntu with kernel version 3.2.0
Now I need a makefile to ease my compilation. This simple code of-course should have a simple make-file as well and there it goes:
obj-m := hello_kernel.o
Yes, just one line and the kernel build system will take care of the rest.
At the time of ‘making’ we should give the path of our kernel source. To find that we should firt find the kernel version you are currently running on. Run ‘uname -r‘ at your terminal.

You will get something like “3.2.0-40-generic”, don’t worry if it’s just numbers. Now the kernel source tree path will be “/lib/modules/3.2.0-40-generic/build”. This will be a soft link to original path and this will do for us.
Now we have our source code in “hello_kernel.c” and make file “Makefile”.
Now run the command
make -C /lib/modules/3.2.0-40-generic/build/ M=`pwd` modules
This command starts by changing its directory to the one provided with -C option, which is your kernel source directory and finds the kernel’s top-level make-file. The M= option is to help the make utility to traverse back to our current directory to build target: modules

Now our module is ready to be loaded. Run the below commands.

You need to have sudo privilege since we are messing with kernel. insmod will load the driver module, lsmod will list all the loaded modules and we are grepping our module from the result and rmmod removes the driver.

Hope you notice that we had a few printk statements in our code but nothing appeared in the console. It is because all kernel specific logs go to “/var/log/syslog” file in Ubuntu. Likewise different Linux distros will have its own specific file. You will see whatever we printed out in our driver code in those file. Just run the below command in our case:

cat /var/log/syslog | tail

There ends our first step towards mastering Linux Device Drivers. Wait till the next chapter for advanced topics..