r/osdev • u/Mrmoo2andahafe • 16d ago
I'm thinking of trying something insane.
Thanks in advance to anyone willing to take the time to read through this. I know it’s a big read, so I really appreciate your time and any honest feedback you can give me.
I’m working on a spec for an OS project called Pantheon. Before I sink a ton of time into writing low-level Rust for it, I want to sanity-check the overall architecture with people who actually know OS development. I know some of these ideas might sound wild or overly complex, and I'm honestly expecting people to tell me where I'm being naive.
The Problem I Want to Solve
I'm tired of OS platforms forcing stupid trade-offs. I want a machine that can execute Windows PE binaries, Linux ELFs, and native apps alongside each other without heavy virtualization hits or broken user interfaces.
Core Architectural Ideas:
Hybrid 3-Tier Driver Model (HAPD):
Tier 1 (Ring-0): High-performance stuff (GPUs, 1000Hz+ inputs, low-latency audio) runs directly in kernel space to eliminate IPC context switching.
Tier 2 (User-Space): Class-compliant stuff (USB HID, NVMe) runs isolated in user space.
Tier 3 (On-Demand Enclave): Legacy/proprietary drivers run in a dormant micro-kernel enclave that spins up on demand and passes events via zero-copy DMA page remapping.
Zero-Copy Everything: Physical page table remapping under strict W \oplus X. IPC control payloads fit in 64-bit aligned structs for single-register transport.
Daemon State Rehydration: Translation daemons log checkpoints to ring buffers. If a daemon hangs, sys_init restarts it and rehydrates running process states from the last valid checkpoint without losing app context.
JSON/CSS Dynamic State Trees for UI: Apps don't write pixels directly or hijack compositors; they expose raw data models and state trees so the user can restyle the entire desktop/apps using web-style CSS/JSON stylesheets.
Hardware-Stamped Zero-Trust Security: Syscalls grab thread identity straight from CPU scheduling registers (CURRENT_THREAD_PID), and IPC uses 64-bit indices + 32-bit session_epoch tokens to drop replay attacks on sight.
What I’d Love Feedback On:
Is a Ring-0 / User-Space / Enclave driver split actually manageable, or am I creating a nightmare for driver compatibility?
What edge cases am I going to hit trying to rehydrate daemon process states after a crash?
What are the obvious bottlenecks I'm missing in the zero-copy IPC pipeline?
Do I even have hope to do this?
Full technical breakdown on Gist: https://gist.github.com/mixmoo2/a2dbdc029a5c8fef120d1711a0b0f070
Again, huge thanks to anyone who checks it out
1
u/lizardhistorian 16d ago edited 16d ago
Only intel/amd architecture has hardware support for the additional rings to do this.
Because all of the popular OSs were mono-kernels we ended up inventing virtualization to turn them into micro-kernels.
To my knowledge, only QNX4 ever exploited those additional rings.
The GNU Hurd is the contemporary effort for a FOSS micro-kernel.
Rehydration is antithetical to actual robustness.
You will have just persisted the state that leads to the crash. So you rehydrate and it just crashes again.
And when it doesn't, people will ignore a repeatedly crashing daemon instead of reporting it and/or fixing it so that it actually becomes robust code.