Compiling the kernel

Andromeda is an interesting project, but in order to see what we’re up to, you might just want to look beyond the code and into the binary.

As of yet, there’s not that much going on, but the mere fact that we’ve got the possibility to boot, handle key-presses and actually have scrolling text on our screens is already quite a feat, for first time kernel programmers like us. Just imagine that the stuff going on in the background is a thousand times more epic than what you can see on screen.

This article will guide you through the building sequence for the Andromeda kernel project. We will start of by getting our tool chain in place. We won’t go into detail on how the tools work by them selves. That’s what Google is for.

Once we’ve got our tool chain in place, we’ll go into basic compiling. With that behind us, we’ll look at the option for providing flags, and last but certainly not least, we’ll go into booting the kernel.

Tool chain

For testing some options are:
  1. KVM/qemu
  2. Virtual box
  3. bochs
Qemu/KVM probably is the easiest, as the “Make test” command uses that.

To compile Andromeda, we will need the following:

  • gcc
  • nasm
  • GNU-Make
  • ld
  • git
The compiler, assembler, make and linker respectively. For the ones that don’t know what the different tasks of those tools are, here’s a brief summary:


The compiler compiles C code, and translates it into binary object files. The C compiler doesn’t know about the layout of the final layout of the binary image. All it knows how to do is translate C statements into machine instructions.


The assembler takes loose human-readable machine instructions and translates them into machine-readable machine instructions. The output is surprisingly similar to that of a compiler.


Make is the tool that is the conductor of this small orchestra. It tells the compiler or assembler to translate their code into binary instructions. Once this is done it tells the linker to put it all together.


The linker is the pasting tool. Until this point our sources have been translated into several binary images, but none of them are executable, because they have references to other files, which need to be linked together first.


Git, the stupid content tracker, is a quick and easy to use version keeping system, that’s used by projects such as the Linux kernel and Android. This will be used to get our code, and maybe even do some work on it. Who knows?!


In order to build the kernel, we’ll be issuing the make command in the src directory of the repository. This command will read the Makefile and based on what we’ve got there it will determine how to compile which source file.

Make takes some arguments. One of them is “-s”. This silences make, and keeps the terminal relatively clean, and easy to read. Only warnings, errors and verbose messages will show up in the terminal, keeping it easy to follow what’s happening.

Another argument is the “-j n” option, in which n is the number of jobs with which you want to compile the kernel. Generally to optimize the compilation for your system, it is best practice to take the number of cores (if you have hyperthreading, you can use that) and double it.

For example I have a core 2 dual, with 2 cores, so my most optimized command is:

make -sj 4

Compiler flags

To activate or disable some functionality in the kernel, there is a possibility to add some flags to the compilation. The easiest way to do this is to put the flags into the flags variable you hand to make. To enable a feature, the -D flag can be used. To disable, the -U flag is to be used. So for example to compile the slab allocator into the kernel the following command can be used:


make FLAGS="-D SLAB"

Work is under way to building a kernel configuration editor, so not all flags will have to either be looked up or be remembered. For now, to find out which flags are available, key in make usage.


There’s a couple of different ways to boot Andromeda. The first and easiest is through the make test command.

Make test builds the source tree (FLAGS variable works with this target as well) and then tries to run it in an Qemu/KVM environment. Qemu has a pretty convenient option to emulate grub, which we take advantage of here. For those that don’t know what Qemu is, it is a virtual machine manager, and KVM means kernel-based virtual machine (the commands can pretty much be used interchangably).

Another way is to create a director at /media/loop and download a floppy image from github. First you build the kernel, according to the instructions above, and then the image is put into the src/scripts directory. Next we issue the ./ command, which will ask you for your sudo password (please install sudo for this, if you haven’t already).

To recap, the options are:

make test


cd scripts
./; kvm -fda floppy.img -m 16M