/Teaching/Operating Systems/Tutorials/Sourcecode layout of SWEB

Sourcecode layout of SWEB

In the following, we are going to illustrate the sourcecode layout of SWEB. When having a look at SWEB for the first time you might be overwhelmed by the big number of sourcecode files. In order to become familiar with the present layout, we are about to give you an overview.

The layout explained

In the following, the content of the most important sub-directories of SWEB is exposed.


This folder houses all different architectures sweb was ported to. This includes

Mandatory tasks will be done in the x64folder inside the x86folder. However you can port your x64 features to every architecture shown in this list. Even non-supported architectures can be implemented e.g. RISC-VSWEB runs on different architectures. You can choose to support one or more architectures during your exercises.  Use gcc arm embedded toolchain and u-boot-toolsare required for arm, e.g. install with  sudo apt-get install gcc-arm-none-eabion ubuntu based systems. You can find the points in the Tutors Points List on the Assignments page.

When looking into x86/64/source/ some important files can be found, namely:

  • ArchInterrupts.cpp
    Here is the code used for context switches when an interrupt is fired.
  • ArchMemory.cpp
    This file will be one of the most important ones. Here you will find the hub for the process’ virtual memory management.
  • ArchThreads.cpp
    Base class of the Thread class for the x86-64 arch.
  • InterruptUtils.cpp
    The hub for serving all interrupts that were fired.


This directory contains architecture-independent code, separated into source (sourcecode) and include (header files) folders. The two directories have the same sub-directories in common, providing different parts of the OS kernel. Some of these components deserve special highlighting:

  • /console: Code for the normal character console as well as the VGA (frame buffer) console. You will only need to change this if you want to change the way text IO is handled.
  • /drivers: Is the directory where you should place all drivers you want to implement. At the moment, it is empty.
  • /fs: A file system abstraction and some concrete, working implementations like MinixFS (a device file system), a RAM file system and a pseudo file system.
    Note especially the file VfsSyscall.cppwhich contains the entry points for all important file system functions for the kernel to use. Unfortunately, though, the filesystem implementation is not threadsafe, so keep that in mind when you are accessing it.
  • /ipc: A few data structures which do not conform to any standard, designed for use by several threads, i.e. to employ locking.
  • /kernel: As the name suggests, this is where the actual kernel is located, including the scheduler, loader, threading and locking support.
  • /mm: The page manager which keeps track of free pages and an implementation of the new/new[] and delete/delete[] operators.
  • ustl: An implementation of the C++ Standard Template Library, the uSTL. If you want to use a standard container (i.e. a vector) from the uSTL, simply include #include “ustl/vector.h”. All available uSTL containers are in the namespace ustl.
  • util: Similar to ipc but data structures in this folder are not thread-safe.


As scary as the rest of SWEB may seem in the beginning, this is a place where you should feel at home immediately. There is no operating system “magic” going on here, it is just normal C programming. Historically, the code is divided into two parts: The libc and userspace programs, residing in the tests directory. The libc contains parts of the C standard library that you should already be familiar with. As you proceed to add more and more functionality to the kernel, you will also need to add code to the libc to provide functionality to user programs (i.e. threading).

Next Chapter