1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
TeachOS Kernel
==============
TeachOS is a modern kernel with a focus on clean design and simplicity.
It is not highly optimized like production grade kernels, but instead aims to be understandable.
It is implemented in assembly and C++, where the amount of assembly is kept to a minimum.
The primary design goal of the kernel is to be teachable and useful as part of the operating systems lecture track at OST.
Development
-----------
Development happens primarily on Linux.
Other platforms (e.g. Windows, macOS) may allow building of the kernel as well, however at the time of writing they are not officially supported.
Required Tools
~~~~~~~~~~~~~~
A precompiled toolchain, targeting only x86-64 as of the time of writing, is available in the `Devconainers <https://gitlab.ost.ch/teachos/devcontainers>`_ repository.
The toolchain is provided both as a downloadable, self-contained archive and an Ubuntu Linux based Docker image.
When using the downloadable archive, care must be taken to make the contained executables available in the user's or system path.
Also, when using the downloadable archive, further required tools, like CMake, QEMU, Ninja, xorisso, grub, etc. must be installed separately.
The primary IDE used for development is VSCodium.
A configuration of runnable tasks, debugging settings, etc. as well as suggested extensions is provided.
Other IDEs might work, especially Visual Studio Code related ones, but no support is provided.
Repository Structure
~~~~~~~~~~~~~~~~~~~~
The code is grouped into separate "sub-packages", according to the following rules:
- ``arch``: The root of all platform-dependent code.
- ``kapi``: The Kernel API, implemented by either the kernel itself, or the platform, used by both.
- ``kernel``: The root of all platform-independent code
- ``libs``: Support libraries, like the TeachOS Standard Library, or Multiboot2 support.
When implementing new features, drivers, or infrastructure, care must be taken as to where to place the new code.
In general, platform-dependent code, like CPU access, MMU configuration, privilege handling etc., should be placed in the relevant folder under the ``arch`` root.
Platform independent-code, like generic memory allocation or scheduling algorithms, or generic drivers for hardware like PCIe devices, should be placed under the ``kernel`` root.
Launching
~~~~~~~~~
The default build target generates a bootable image.
On x86-64 for example, this image takes the form of a bootable, grub2 based ISO image.
These images are designed to be booted in QEMU, and should theoretically also be bootable on real hardware.
However, note that not warranty is provided, and the kernel code may irreparably destroy any physical hardware if booted on a real system.
The VSCodium IDE configuration provides a launch task using QEMU, available for debugging (via F5) and direct launch as a task.
Notes for Development under Windows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
While this repository and the devcontainer can be used from Windows, significant performance issues may occur.
To reduce these issues, you can either set up a Linux VM for development, or, if that is not preferred, clone the repository inside WSL and open it from there with Visual Studio Code.
| ``git clone <repo-url>``
| ``cd <repo-folder>``
| ``code .``
If you use tools such as Git Extensions or GitHub Desktop, access the repository via the WSL network path, for example ``\\wsl.localhost\<distro>\<path-to-repo>``.
|
