Version 6 is a hobbist operating system designed to let one mess with underlying tech that normally isn't used in day-to-day high level development. I've been playing with OS development since college, and this is the sixth iteration (over 20-years) of my hobbyist OS.
All code is open sourced, written by Adam Holisky in his spare time unless otherwise noted.
Contact me VIA: Email adam.holisky@gmail.com -- Twitter @adamholisky -- BlueSky @adamholisky.bsky.social
A small, lean operating system/supervisor that allows direct hardware interfacing useful for tinkering with different aspects of modern technology. Runs on x86 and ARM processors with an abstracted technology layer, masking differences between architectures.
The "Big Goal" for right now is to laser focus on getting a Telnet connection established via TCP/IP over an emulated Ethernet device and network.
Goal | Status | Comments |
---|---|---|
Keep it simple | 🟢 | Prefer readablity over optimization whenever possible |
C++, C, Assembly | 🟢 | Prefer C++ when possible, otherwise C and Assembly as needed |
Clean build system | 🟢 | Don't over-complicated the build system, but don't shy away from advanced topics |
Completely in x86_64, no 32bit code | 🟢 | Loaded via Limine |
Basic paging | 🟡 | Allocating and page maping with own page tables |
Basic memory management | 🟡 | Linear allocator |
Basic interrupts | 🟡 | Enough to handle exceptions, timer, etc... |
I/O via Serial | 🟢 | Debug out and stdio via QEMU's serial ports works |
In-OS sanity checks | 🟡 | Some sanity checks run regardless, more run when debugging is enabled for specific code blocks |
Basic console on framebuffer | 🟡 | Good enough, maybe |
PCI | 🟡 | Good enough to get basic info for devices |
Ethernet | 🟡 | Good enough, maybe |
ARP | 🟡 | Protocol works, need to do dictionary |
IP | 🟡 | Good enough, maybe |
DHCP | 🟡 | Good enough, maybe |
TCP | 🟡 | Working in a PoC stage |
Task Management | 🟡 | Yielding-based, handles crashes |
Telnet | 🟠 | Working in a very basic way |
HTTP/Json | 🔴 | Not started |
Goal | Status | Comments |
---|---|---|
ARM support | 🔴 | TBD |
Smooth looking Text UI | 🔴 | Borland C called and wants its UI back |
Scripting language | 🔴 | Sketched out basic HyperTalk-like language |
Heap memory managment | 🔴 | Ready to be implemented, mostly independent of paging |
Unit tests | 🔴 | TBD |
Run on real hardware | 🔴 | Should be possible to do with a basic board |
The host system should have set up:
- Cross-compile GCC, G++, GAS, ELF Linker
- QEMU emulating x86_64
- Some sort of loopback/disk image mounting
Makefile targets are clearly outlined in the Makefile
, with supported includes in the build_support/control/*.mk
files, notably the toolchain.mk
file which contains direct links to the compilers that the build system will use.
make
run by itself in the root directory will build the system.
From the root directory, do a make run
to execute the OS's normal operation path.
For normal execution, the Makefile and QEMU are configured to send data accordingly:
build_support/logs/build.log
Output for the build commandsbuild_support/logs/elfdump.txt
ELF information for compiled kernelbuild_support/logs/objdump.txt
Full disassembly for compiled kernel, including final addresses via the linkerbuild_support/logs/serial_out.txt
Running serial log from OS's COM4 port outputbuild_support/logs/qemu_debug_log.txt
has a bunch of detailed output from QEMU, very useful for tripple faultsstderr
Error output from G++, etc...stdin/stdout
QEMU's "terminal" in/out, sending to/from in OS's COM1 port I/O
From the root directory, run make run_debug
to boot the OS with QEMU accepting remote connections to port 5984. Run make gdb
to run GDB using the configuration in the build_support/gdb_control/commands.gdb
file (TUI, some shortcuts, etc...)
Breakpoints are manually listed in the commands.gdb
file.
This is genereally the order that I'm going to build things.
Limine boot into x86 64bitMakefile cleanup, loggingSerial outPort the libc back to 64bit and verify it basically worksDebug loggingFind paging data from limine, use it or my own entirelyInterruptsInterrupt debug displayPage allocation and allocatorLinear memory allocatorKernel symbols loaded via ELF processing, used in crash handling- Stackframe back trace
- PCI
- Ethernet
- ARP
- Ping
- Telnet