This article is about a suggestion for making kernel work easier. The next article will be about how to implement the suggestions I make.
Kernel coding is a bit of a pain, if you compare it to userspace coding. You loose a lot of nice things in userspace, like segfaults (think you can’t live with them? try living without them 😉 ), and a bad kernel build can easily stop a system cold. These stupid little annoyances can really stop beginners from getting involved! Figuring out how to work around this took me longer than I had hoped, and I’m going to share some of the things that made kernel work go from an omg-pain-in-the-arse to only marginally more painful than userspace coding 🙂
Firstly, I’ve really taken a shine to working in a nice VM sandbox environment for a few reasons:
How can we avoid these three barriers to kernel coding? Easy. Boot the kernel up in a virtual machine, like qemu. The virtual machine stops you from messing up your physical machine with a (potentially) wonky kernel. Furthermore, if the kernel panics in the virtual machine, you can easily shut it down, and preserve all the programs and documentation you’re using. If you do run into a panic or crash, the virtual disk image is still there after you power the virtual machine down, allowing you to view any crash logs without booting the system again. Finally, when you have to boot into a new kernel, you don’t have to kill all your programs you’re using to get the new build going.
Now, for the warnings! As with most things, there are trade-offs. Working in a sandbox kernel environment under a VM is nice for most of the reasons stated above. However, if you’re doing things like device driver development, its often very inadequate to just work in a VM. No matter what development you’re doing, the eventual end-game for your work is to be deployed on a real machine. You don’t want some flawless latest-and-greatest code you’ve written to work perfectly in QEMU, and panic ‘n crash on a real machine!
All in all, simply working with a virtual machine 80% of the time is a lot nicer than working with a physical machine 100% of the time, and has really allowed me to not exhaust my patience when working with kernel code.
Next article (published tomorrow) will be a brief how-to for how I set up a kernel sandbox.