> Me today, still writing server applications, but now in Go, lives somewhat more remotely from the low level details of the system. There are more abstractions between me and the system. It is rare that I even have to deal directly with, for instance, low level networking system calls (except the odd ioctl, which, as someone pointed out years ago, is the carpet under which we sweep all the things that we couldn't figure out how to do properly).
This is both a disadvantage and a major advantage.
The disadvantage is that yes, changing syscalls / libc is not enough. No one is going to hand-write the FFI for your fancy new syscall; it needs to percolate down to the library they are actually going to use. That percolation takes time, and the extra latency makes this sort of reform project less enticing.
The advantage is when the library interface already works with the new system call. For example, someone pointed out the Go already doesn't expose fork/exec because it wouldn't work on Windows. Well, the proposed process spawning interface might not only support Go's interface, but make it easier to implement.
If we can swap out a standard library implementation once, and then a huge number of applications instantly benefit, that really boosts the cost/benefit ratio!
I myself do not write applications in C either. I mainly notice these bad syscalls when the higher level library interfaces all of the sudden get really awkward for no good reason.
> The second is that we should be careful about putting too much stuff in the OS that really belongs in libraries or applications.
Yes absolutely agree. I meant to talk to about interfaces while being agnostic about what thing implements them. I would be perfectly happy if the OS didn't implement a file system at all.
The reform approach probably does mean adding yet more system calls to existing heritage kernels. But that must not be the entire story. Ideally things look like this:
1. Implement more system calls in heritage kernels with better semantics.
2. Userland software can switch to new system calls and become simpler. Ideally it uses fewer different system calls than before.
3. New greenfield kernels can support the improved/simplified userland software with less work / fewer constraints.
In this manner I hope we can "pivot" to better things. (The pivoting reminds me of parallel parking n-point turn a bit, in that a bunch of small steps with a lot of "wash" somehow combine into something more impressive.)
This is both a disadvantage and a major advantage.
The disadvantage is that yes, changing syscalls / libc is not enough. No one is going to hand-write the FFI for your fancy new syscall; it needs to percolate down to the library they are actually going to use. That percolation takes time, and the extra latency makes this sort of reform project less enticing.
The advantage is when the library interface already works with the new system call. For example, someone pointed out the Go already doesn't expose fork/exec because it wouldn't work on Windows. Well, the proposed process spawning interface might not only support Go's interface, but make it easier to implement.
If we can swap out a standard library implementation once, and then a huge number of applications instantly benefit, that really boosts the cost/benefit ratio!
I myself do not write applications in C either. I mainly notice these bad syscalls when the higher level library interfaces all of the sudden get really awkward for no good reason.
> The second is that we should be careful about putting too much stuff in the OS that really belongs in libraries or applications.
Yes absolutely agree. I meant to talk to about interfaces while being agnostic about what thing implements them. I would be perfectly happy if the OS didn't implement a file system at all.
The reform approach probably does mean adding yet more system calls to existing heritage kernels. But that must not be the entire story. Ideally things look like this:
1. Implement more system calls in heritage kernels with better semantics.
2. Userland software can switch to new system calls and become simpler. Ideally it uses fewer different system calls than before.
3. New greenfield kernels can support the improved/simplified userland software with less work / fewer constraints.
In this manner I hope we can "pivot" to better things. (The pivoting reminds me of parallel parking n-point turn a bit, in that a bunch of small steps with a lot of "wash" somehow combine into something more impressive.)