Kernel Sandbox

January 8th, 2010 by Kevin

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:

  • Stupendously bone-headed kernel hacking can do funny things to your computer, including bricking it, turning off some part somewhere, and having to wade through documentation to figure out what is going on, or simply causing a system crash.
  • Rebooting into a new kernel each time is very annoying. When coding in the kernel (especially if you’re just tinkering with things in the core like I’ve been doing lately), you need to boot into that kernel to test your changes. Waiting the 30 seconds is pretty annoying, and then, all your programs and documentation you had up all have to be re-started. If this sounds like pointless whining, just try spending 40% of the time you are working on rebooting, restoring, and waiting for the machine to do its thing.
  • Kernel panics are the worst. These are simply caused when something very wrong happens in the kernel. The infamous blue screen of death is the result of a Windows kernel panic. This being said, if you’re developing or tinkering with a kernel, there’s a mild chance that you’re gonna cause a kernel panic at some point or the other. If you’re testing on a real machine, a kernel panic will lock your computer up, you’ll lose work you’ve been doing, etc.



    • 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.

    Hazard!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.

    Posted in Open Source

    4 Responses

    1. Aanjhan

      January 9th, 2010 at 4:44 am

      Nice start! Keep them coming! Am sure its going to help lot of high enthu to-be kernel hackers.

    2. Dietrich T. Schmitz

      January 9th, 2010 at 11:01 am

      I am trying to hunt down a kernel panic.

      The laptop refuses to boot unless I use kernel boot option ‘nosmp’ or ‘nolapic’.

      Anything else and it stops after a few seconds into boot.

      Very frustrating because the true issue never reaches the logs.

      I am running Ubuntu 9.10 AMD SMP compile.

      (The bios is Phoenix and there isn’t any setting to make there other than toggle AMD-VT, which is enabled.)

      AMD Turion64×2 HP dv2000z Pavilion laptop.

      Any ideas on how to trap the error?

      Thanks for the good article.
      Dietrich T. Schmitz

    3. Links 9/1/2010: Wine 1.1.36, 2010 Spring Alpha1 | Boycott Novell

      January 9th, 2010 at 11:24 pm

      [...] Kernel Sandbox 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. [...]

    4. medvedev

      January 19th, 2010 at 4:33 am

      вот и поздравили…=)

    Leave a Comment

    Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.

    Creative Commons License CC-GNU GPL
    By using this site, you agree to its terms of service.
    All content copyright (c) Kevin DuBois 2006-2009