It would be sad if we, as an industry, do not take this opportunity to create a better OS.
First, we should decide whether to have a microkernel or a monolithic kernel.
I think the answer is obvious: microkernel. This is much safer, and seL4 has shown that performance need not suffer too much.
Next, we should start by acknowledging the chicken-and-egg problem, especially with drivers. We will need drivers.
So let's reuse Linux drivers by implementing a library for them to run in userspace. This should be difficult, but not impossible, and the rewards would be massive, basically deleting the chicken-and-egg problem for drivers.
To solve the userspace chicken-and-egg problem (having applications that run on the OS), implement a POSIX API on top of the OS. Yes, this will mean that some bad legacy like `fork()` will exist, but it will solve that chicken-and-egg problem.
From there, it's a simple matter of deciding what the best design is.
I believe it would be three things:
1. Acknowledging hardware as in [1].
2. A copy-on-write filesystem with a transactional API (maybe a modified ZFS or BtrFS).
3. A uniform event API like Windows' handles and Wait() functions or Plan 9's file descriptors.
For number 3, note that not everything has to be a file, but receiving events like signals and events from child processes should be waitable, like in Windows or Linux's signalfd and pidfd.
For number 2, this would make programming so much easier on everybody, including kernel and filesystem devs. And I may be wrong, but it seems like it would not be hard to implement. When doing copy-on-write, just copy as usual, and update the root B-tree node; the transaction commits when the root B-tree node is flushed to disk, and the flush succeeds.
(Of course, this would also require disks that don't lie, but that's another problem.)
Would you like to mention what kind of expertise you have to state that a microkernel is obviously better, and in what sense it's better? And also explain how is it that microkernels already exist and no one cares? Especially the ones older than Linux?
First, we should decide whether to have a microkernel or a monolithic kernel.
I think the answer is obvious: microkernel. This is much safer, and seL4 has shown that performance need not suffer too much.
Next, we should start by acknowledging the chicken-and-egg problem, especially with drivers. We will need drivers.
So let's reuse Linux drivers by implementing a library for them to run in userspace. This should be difficult, but not impossible, and the rewards would be massive, basically deleting the chicken-and-egg problem for drivers.
To solve the userspace chicken-and-egg problem (having applications that run on the OS), implement a POSIX API on top of the OS. Yes, this will mean that some bad legacy like `fork()` will exist, but it will solve that chicken-and-egg problem.
From there, it's a simple matter of deciding what the best design is.
I believe it would be three things:
1. Acknowledging hardware as in [1].
2. A copy-on-write filesystem with a transactional API (maybe a modified ZFS or BtrFS).
3. A uniform event API like Windows' handles and Wait() functions or Plan 9's file descriptors.
For number 3, note that not everything has to be a file, but receiving events like signals and events from child processes should be waitable, like in Windows or Linux's signalfd and pidfd.
For number 2, this would make programming so much easier on everybody, including kernel and filesystem devs. And I may be wrong, but it seems like it would not be hard to implement. When doing copy-on-write, just copy as usual, and update the root B-tree node; the transaction commits when the root B-tree node is flushed to disk, and the flush succeeds.
(Of course, this would also require disks that don't lie, but that's another problem.)
[1]: https://www.usenix.org/conference/osdi21/presentation/fri-ke...