An experimental toy kernel/OS written using Zig as much as possible. Assembly will be used where required for funtionality (e.g loading the GDT in x86/x64), however this ideally will be done using inline assembly rather than seperate assembly files.
Currently the only supported architecture is x86_64 (x64). However the project should hopefully be setup and configured in such a way that if I (or maybe someone else) decides they want to learn and support another architecture then this could be relatively easily implemented.
All the features currently implemented and also the implementation progress of planned future features.
- Boot
- Boot with Limine straight into 64-bit (long mode)
- Kernel
- Internal logging system
- Kernel stack
- Panic
- Print stack trace (and possibly other useful information) from panic
- Expand Panic to output full stack traces and other useful information
- Architecture
- x86_64
- Serial port I/O
- Apply a mutex to reading and writing with the serial port.
- GDT and TSS
- Interrupts
- Setup IDT
- Enable Interrupts
- Create ISR handlers
- Create IRQ handlers
- Configure PIC
- Configure APIC (then disable PIC)
- Memory Management
- Get the Memory Map from Limine
- Physical Memory Manager
- Virtual Memory Manager
- Allocator
- Paging
- Higher Half, while already there we might want to work out if we ware in the right location or do we want to move
- Ensure the permissions of the different kernel ELF sections are correctly applied, for example .text should be read-only, .data should be read-write, .rodata should be read-only, and .bss should be read-write.
- Serial port I/O
- x86_64
- Terminal
- Framebuffer
- Request from limine
- Clear screen
- Draw pixels to screen.
- Fonts
- Bundle font into kernel
- Load PSF fonts
- Draw fonts / characters
- Parse Unicode table if there is one and use it.
- Save font(s) to disk and then load dynamically as/if they are needed.
- Write text to screen
- Apply a mutex to writing to the screen
- Add color support
- Add ANSI support: ANSI (American National Standards Institute) a standardised system of escape codes that modern computer terminals should understand. These escape codes allow a computer program to manipulate terminal color, text effects, clear the screen and move the text cursor around. ANSI Escape Codes - Wikipedia.
- Add Scrolling
- Keyboard Input
- Add cursor?
- Framebuffer
- Filesystem(s) & Storage drivers (HDD, CD, FLP, Ramdisk)
- Internal Debugger
- Testing
- Setup test framework for OS using a custom test runnner
- Integrate test framework with GitHub actions CI
- Don't always run tests in the same order (we should probably have some way of regenerating the order that we use however)
- Add configurable timeout to each test run (default 5 minutes?) in case we get a situation where we hit and endless loop?
- Long Term (probably the far far far far farrrrrrr future)
- User Space
- Switch to (Ring-3)
- System Call(s)
- Program Loading (ELF executables?)
- ACPI parsing
- Time / Timers
- CMOS
- PIT
- HPET
- Multithreading / Multiprocessing
- Threads
- Thread Local Storage
- Thread Lists for different priority levels
- Scheduler
- A scheduler not ready for multiprocessing will probably be fully rewritten.
- Priority Levels: Design in such a way, so threads/processes can have different priority levels.
- Multiprocessing
- Symmetric Multiprocessing
- Graphics / User Interface
- Networking
- Sound
- USB (Universal Serial Bus)
- Porting Software (e.g compiler)?
- User Space
This section contains all of the information you need to be able to build, run, debug, or test ZagOS.
There's a few tools required to build and/or run the OS. If you're on Ubuntu with snap installed (or similar) then you can just run the following commands and it will install everything you should need:
snap install zig --classic --beta
sudo apt update
sudo apt install build-essential gdb grub-common qemu-system-x86 xorriso
However if not then you'll need to install Zig 0.14.0 as well as ensure you have the following tools available on your system:
- grub-mkrescue
- make
- xorriso
If you want to do any debugging, testing, or running you'll probably want these as well:
- gdb
- qemu
You can build the OS by running:
make build
This will download the bootloader (Limine) and build it, before compiling the kernel and assembling everything together into a single bootable ISO image (ZagOS.iso
).
There's a couple of different options you can change in the Makefile
to configure the OS. The available options are at the top of the file and all of the possible values are listed, you can also see the value below.
# Available architecture targets: x86_64
ARCH := x86_64
# Available optimization levels = Debug, ReleaseSafe, ReleaseFast, ReleaseSmall
OPTIMIZATION_LEVEL := Debug
To generate and run an ISO image of ZagOS with Qemu you can run:
make run
This will launch the latest generated ISO image in Qemu with all the standard configured flags. These flags can be edited within the Makefile
in case you wish to use a slightly different configuration for Qemu.
You can run the ZagOS in debug mode which will then launch Qemu and then wait you to connect with gdb by using the command:
make run-debug
Alternatively if you use VS Code then this can be done from within the editor by using the inbuild tasks (or just press F5), this will then automatically connect with GDB for you.
Similar to previously all of the unit/integration tests can be run via:
make run-test
This will launch the OS in test mode the the custom Zig test runnner and execute all of the tests which are found outputting the results to the screen and producing an error code on failure.
This project is licensed under the Unlicense (LICENSE or https://opensource.org/license/Unlicense), with the exceptions of the 3rd party software/assets which are noted below
ZagOS depends on several other projects for assets and/or software. These dependencies are NOT covered by the for ZagOS License. These are instead licensed as described by each individual project's documentation, and with the licenses used by said projects linked in the list below:
All contributions are welcome in whatever form, from bug reports to feature suggestions, or best of all pull requests.
Some very helpful documents which can be useful for developing this OS: