Linux Kernel Programming – 2

Reading Time: 2 minutes

In the first tutorial I did a little hands on writing a Linux Kernel module. The idea was to get the fear out that you’ve to learn too much before even starting on a Hello World module.

In this tutorial I’m going to talk a bit about how operating systems work in general and where does our Hello World kernel module fits in.

The always busy kernel!

Operating systems are more or less invisible to the world, that’s the way they are. It’s a mediator, resource arbitrator however it doesn’t do anything on its own. It just sits there waiting for someone to poke it, literally wake it up.

You can think of operating system as a bank with multiple security layers but if there’s nobody in the bank you won’t see anyone ever working, but they are, you just don’t know it yet.

Obviously with time a bank will offer more services same way an Operating system can extend the services provided via extensions to kernel, known as kernel modules. Again if nobody is asking for this new service in the bank no issues, however it still is part of the bank services and can be used in case some customer comes asking for it.

Interfaces - The bridges we use

Like in a bank if you need money or need to deposit it, you go to a teller with your request. Same way with kernel you need to make a request for the kernel. This request is done in the form of a system call  from programs. 

Just like there could be multiple type of services and they could’ve different forms to be filled in a bank,  system calls also vary in type and number of arguments they take. The analogy is quite direct.

Now imagine there are multiple people who want to withdraw / deposit money or maybe use some other service. There’s only a limited number of tellers / customer executives available and they can only serve one at a time. Banks have resolved it either by using a queue or a token system to maintain discipline.

The kernel also provides several resource locking mechanisms. We just have to use the correct one for the service which we’re trying to add into kernel. No user program can violate these mechanisms since they’re part of kernel, much like our bank example.

Obviously without an interface all the services become inaccessible and then there’s no fun. There are also instances when a bank might’ve to deal with incorrect forms for the service and every once in a while a mistake happens which needs to be duly sorted out by the bank. The same can happen with kernel however there are not as much possibilities of an outcome as there are with a bank 🙂

The way forward

Kernel programming can be quite fun, however the interfaces to use those services added are well, quite rigid. You’ve to write your code in a certain way because of the already established rules (protocols) .

However there are some ready to use boiler plate constructs which don’t require too much fiddling with the internals. You’ll however have to go and check how things work behind the scenes at some point.

Everything is a file interface definition of *NIX systems is very much prevalent in Linux as well since it provides the abstraction we need and can be plugged into other services to create even larger abstractions. In the next tutorial we’ll learn about these constructs a little bit and again some hands on is absolutely necessary to understand what’s going on!

Leave a Reply