Some Feelings of Developing for Linux Kernel Module
Tert-Butyllithium

Recently I have been concentrate on the development of a kernel module. During the whole work, I have underestimated its difficulty many times, and here are my feelings.

Hard to debug

Kernel module extends Linux kernel, while has the same privilege and address space. Therefore many bugs in the kernel module (e.g., buffer overflow, null pointer) will make the kernel crash. In this case, we need to reboot the machine, which will inevitably affect our progress.

For comparison, the crash of an ordinary program in user space, usually handled by the library or OS, shouldn’t influence other parts of the system. Besides, we have a lot of tools like debugger or IDE. The damage caused by a user program is limited.

This problem can be solved in two ways:

  • virtualize: using hypervisor like qemu and use its debug tools
  • split the entire kernel module into small components, and then test them in user space sufficiently before migration to kernel space.

Concurrency

For a toy kernel module, i.e., only the code fragments in init and exit are useful, it’s just an execution of a piece of code with higher privileges (e.g, change some privileged system registers). However, the concept of the kernel module is designed for interaction with the Linux kernel. Consequently, your code becomes a functional enhancement of the Linux kernel, and its scheduling is a black box(surely you can learn every detail of its mechanism as Linux is open source).

In this way, a high degree of concurrency is common, and have to consider concurrency bugs…