Show HN: Anos – a hand-written ~100KiB microkernel for x86-64 and RISC-V

Note This is not yet an operating system, but definitely has reached "toy kernel" status, since it now supports user mode preemptive multitasking on up to 16 CPUs, provides enough kernel support to run functioning device drivers in userspace, and runs on real hardware 🥳. Anos is a modern, opinionated, non-POSIX operating system (just a hobby, won't be big and professional like GNU-Linux®) for x86_64 PCs and RISC-V machines. Anos currently comprises the STAGE3 microkernel, SYSTEM user-mode supervisor, and a base set of servers implementing the base of the operating system. There is a (WIP) toolchain for Anos based on Binutils, GCC (16-experimental ) and Newlib (with a custom libgloss ). Anos is free software licensed under the GPLv2, with similar linkage exceptions as other major free operating systems. - Non-zealous microkernel ( "STAGE3" ) with scheduling, memory management, and IPC primitives - Strict system-wide capability-based security model - User-space system management server ( "SYSTEM" ) provides common OS abstractions - User-space ACPI or Devicetree-based hardware discovery and driver model (WIP) - Custom software-development toolchain (based on binutils, GCC and Newlib) - Requirements (theoretical min/max): 1 core, 256MiB RAM / 16 cores, 127TiB RAM As far as the Kernel is concerned, there's much to still be decided, and most of what has been decided could still change without notice. Since this is being designed as 64-bit from the beginning, there's a lot of things I can do that I wouldn't otherwise be able to, and I'm experimenting with a few different ideas. Decisions I've taken so far are, briefly: - Non-zealous microkernel providing only: - Bare-minimum drivers for hardware used in the kernel itself - CPU (both x86_64 and RISC-V) - Basic timers (HPET, TSC, SBI Timers on RISC-V) - Interrupts (LAPIC, MSI / MSI-X, S-mode interrupts) - Physical / virtual memory management (48-bit on both architectures) - Thread / Process management & address space primitives - Scheduling (and directly-related concurrency primitives) - IPC (synchronous, zero-copy message-passing) - See the in-depth documentation for details - Small, targeted syscall interface - Fast channel (via SYSCALL andSYSRET on x86_64, orecall on RISC-V) - Slow channel (via int 0x69 [deprecated, not cross-architecture]) - See the in-depth documentation for details - Fast channel (via - Delegatable capability-based syscall control - Bare-minimum drivers for hardware used in the kernel itself - *User-mode SYSTEM supervisor providing operating-system services - Basic userspace bootstrap - Userspace configuration - Userspace process-management interface - VFS - SYSTEM coordinates activities of other services to provide: - Hardware drivers: PCI, AHCI (via capability-based MMIO) - User mode terminal / log output - Networking - GUI - USB (xHCI) (WIP) - Limited / no legacy support - x86_64 required, no PIC / PIT etc, - Minimum "supported" architecture: Haswell (4th gen) (Items in bold are already implemented, for some value of the term. If you want more detail they are, as far as possible, documented in the linked documents / source / comments). The basic idea is most user processes will have very limited syscall capability - and instead will use (hopefully) fast IPC to request services from the user-mode supervisor and directly from other services. The supervisor itself is endowed with all capabilities, and will be responsible for delegating said capabilities appropriately to other processes as they are started and depending on their requirements and trust level. Processes exist in a hierarchy, with processes that have the capability to start other process further be able to delegate capabilities they hold to other processes they supervise. Things are developing quite nicely, if I do say so myself. We have enough support for everything (page fault handling, IDT, virtual memory management, etc) to be able to get to a multitasking user mode and then back via a simple syscall interface (accessible via both int and syscall interfaces on x86_64, and ecall on RISC-V). Scheduling is currently handled by a simple prioritised round-robin scheduler with four priority classes and 255 priority levels per class. The design is currently simple and rather suboptimal, and there are significant opportunities for improvement in this area. Note SMP support is currently x86_64 only. On RISC-V, only the bootstrap hart is spun up and used at the moment. SMP on that architecture is WIP currently. SMP is supported, up to a maximum of 16 symmetric cores (one BSP and 15 APs) - although anything over 8 cores will be unstable right now as I haven't made the switch to x2APIC. The scheduler operates on a per-CPU basis and is driven by each CPU's independent local APIC timer. The plan is to migrate this to a tickless design in the near future in order to improve power efficiency in the final design. Note Realtime scheduling is, like realtime behaviour in general, a non-goal of th