0nera/bmosp

Purpose and execution model

BMOSP is an educational, modular x86_64 platform rather than a general-purpose OS. It targets BIOS/UEFI boot and is intended primarily for QEMU. The kernel is built as a freestanding C/GAS image, booted through Limine, then extended with separately built runtime modules. Top-level build/run entry points are build.sh, build_mods.sh, and run.sh.

Boot and kernel initialization

Limine boot configuration and image layout are defined in configs/limine.cfg and configs/linker.ld. Kernel control begins in kernel/start.c, which establishes the platform runtime and coordinates early subsystem initialization. Architecture-specific setup is concentrated under kernel/cpu/arch.c and kernel/cpu/cpu.c.

CPU, interrupts, and scheduling boundary

The x86_64 hardware layer configures descriptor tables, interrupt handling, PIC/PIT timing, paging, and task switching. Key paths are kernel/cpu/idt.c, kernel/cpu/idt_stubs.s, and kernel/cpu/paging.c; task execution/switching spans kernel/cpu/task.c and kernel/cpu/task_switch.s. This layer is the boundary between raw processor events and kernel services.

Kernel services and shared interfaces

Core services include memory management, framebuffer output, logging, synchronization, buffered I/O, and general system calls/services. Their implementation resides in kernel/mem.c, kernel/fb.c, kernel/log.c, kernel/lock.c, kernel/io_buf.c, and kernel/sys.c. Public kernel-facing contracts are exposed through headers such as include/mem.h, include/sys.h, include/fb.h, and include/mod.h; modules should depend on these interfaces rather than internal kernel files.

Module loading and executable format

The platform’s defining extension mechanism is dynamically managed modules. kernel/mod.c owns module lifecycle/loading behavior, while kernel/elf.c handles ELF-format executable/module parsing. Module ABI and system-facing types are supplied by modlib/modstd.h, modlib/system.h, and modlib/types.h. The module linker layout is defined by modules/link.ld.

Modules and device/application functionality

Modules are independently compiled C components with their own build.sh entry points. They provide demonstrations and platform capabilities: example output (modules/helloworld/main.c), in-memory filesystem behavior (modules/imfs/main.c), PCI discovery (modules/pci/main.c), PS/2 input (modules/ps2/main.c), and a Doom workload (modules/doom/main.c). The module catalog is represented by modules/modules.json.

Build, SDK, and delivery infrastructure

Build scripts assemble the kernel, module artifacts, boot configuration, and image/runtime workflow. build.sh is the primary kernel build orchestrator; scripts/build_sdk.sh and scripts/get_sdk.sh manage the required SDK/toolchain; scripts/modmanager.py supports module management. CI, static analysis, and release automation run in GitHub Actions through .github/workflows/build.yml, .github/workflows/codeql.yml, and .github/workflows/release.yml.