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-V. SWEB runs on different architectures. You can choose to support one or more architectures during your exercises. Use
arm embedded toolchain and
u-boot-toolsare required for
arm, e.g. install with
on ubuntu based systems. You can find the points in the Tutors Points List on the Assignments page.
sudo apt-get install gcc-arm-none-eabi
When looking into
x86/64/source/ some important files can be found, namely:
Here is the code used for context switches when an interrupt is fired.
This file will be one of the most important ones. Here you will find the hub for the process’ virtual memory management.
Base class of the Thread class for the x86-64 arch.
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
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
ipcbut 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).