by vacuity | 2025-10-09 21:43:22+00:00
I certainly can't claim to have discovered these ideas, though perhaps I am one of the earliest to propose gutting the kernel as heavily as I am (the riskiest manoeuver out of my proposals).

> This is more radical than the other great idea of moving the scheduler and the concept of time(sharing) itself to userspace

The idea of userspace scheduling has been explored widely. Hydra took the plunge, but the L4 community is still reluctant. For good reason, since this typically increases latency on a latency-critical path. This is one of the strongest motivations for optimizing context switches by increasing kernel-user colocality in the same address space.

> I quite like your idea of making the kernel unaware of threading

See scheduler activations[0]. Even seL4 has kernel threads, which I think developed mainly due to being used to it, when the alternative would be better for formal verification.

> So effectively ring 0 should only have to deal with enforcing capability security, while everything else lives in userspace.

That's the idea, but unlike seL4 and Barrelfish, I think wholly implementing the capability system is very inflexible. The capability representations are rigid, which fixes (i.e., makes static) performance and fixes policy (all mechanisms restrict policy somewhat). It defies programmability. That's why I want to move most of the work to the trusted userspace process, though for the specific architecture I'm thinking of, it could be another module in kernelspace instead.

Further reading:

[0] https://homes.cs.washington.edu/~tom/pubs/sched_act.pdf | Scheduler activations involve scheduling by physical cores instead of kernel threads. Applications will be notified when losing or gaining a scheduler activation (a context in which to execute code), such as on preemption or initiating a blocking I/O call, or the reentry from those actions. This makes user-level threading more powerful, as well as any concurrency model, since the hardware is more accurately exposed.

[1] https://barrelfish.org/documentation.html | https://barrelfish.org/publications/barrelfish_sosp09.pdf | https://barrelfish.org/publications/barrelfish_hotos09.pdf | Barrelfish is a research OS that extends seL4's capability system to multicore machines in a principled manner. It also addresses hardware heterogeneity and increased complexity in hardware by using declarative techniques broadly.

[2] https://www.usenix.org/legacy/events/osdi99/full_papers/hand... | The Nemesis operating system focuses on interactive media applications. A major limitation of many OSes is that memory management is not well treated as a latency-inducing subsystem. Self-paging means making each application handle its own page faults, clarifying time usage for memory management.

[3] See the papers I linked in https://news.ycombinator.com/item?id=45522131

[4] https://dl.acm.org/doi/10.1145/2517349.2522720 | A great overview of the technological distinctions of the L4 microkernel family, emphasizing seL4

[5] https://dl.acm.org/doi/10.5555/2685048.2685051 | A Barrelfish paper that modularizes the kernel further, allowing superb flexibility such as easily swapping out the kernel running on a core