So, you want to write a kernel module. You know C, you've written a few normal programs to run as processes, and now you want to get to where the real action is, to where a single wild pointer can wipe out your file system and a core dump means a reboot.

FreeBSD 7.0 has already been released. If you are a real hacker, the best way to jump in and learn it is hacking together an introductory kernel module. In this article I’ll implement a very basic module that prints a message when it is loaded, and another when it is unloaded. I’ll also cover the mechanics of compiling our module using standard tools and rebuilding the stock FreeBSD kernel.

Device drivers can make or break an operating system. The best engineered kernel is useless if applications running on it cannot interface with the outside world or if device manufacturers cannot readily support it with their wares.

One long-running controversy in the open source community has to do with device drivers and whether binary modules (proprietary code provided by device manufacturers, such as Nvidia) should be allowed within the Linux kernel.

For all aspiring kernel hackers, here is sample module which will create a file in /proc filesystem. The file when read by programs like "cat" displays the current process being executed by the kernel. The link contains source code for the module. If you don't know how to compile and test it, visit http://sa-swargam.blogspot.com/2009/08/how-to-test-sample-module-for-cre...

It's all over the Internet now: the Linux kernel developers have issued a statement urging vendors to release open source device drivers/modules. The point is that the timing is actually wrong.

In an historic move, Microsoft Monday submitted driver source code for inclusion in the Linux kernel under a GPLv2 license.

The Introduction says the goal of the book is “to help you improve your understanding of device drivers under FreeBSD”. OK, that is exactly what I wanted to do as I am currently working on several projects that use FreeBSD at deeper levels of understanding.

This week, we'll pick up where we left off last week and continue discussing simple kernel and module debugging using seq_file-based proc files.