Comment by sph
7 days ago
I appreciate the effort that went into this rant a lot (I need to reread it after coffee has fully kicked in), and it touches some ideas I’ve accumulated over the years.
If you still feel in sharing mood, feel free to post links to interesting papers or proof of concepts in the space for further education.
EDIT: I quite like your idea of making the kernel unaware of threading, though I'm not sure how to go about implementing that. This is more radical than the other great idea of moving the scheduler and the concept of time(sharing) itself to userspace (I've seen a few talks about it on YT, I forget the name of the project that explored this avenue). So effectively ring 0 should only have to deal with enforcing capability security, while everything else lives in userspace.
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://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