Conversation

molten take: i'd much rather see rust in the kernel than all of this ebpf nonsense

2
0
1

@ariadne “just add a just-in-time recompiler in the kernel it will be fine” — mf who never heard about the concept of microkernels

0
0
0

even more molten take: I'd rather see the linux kernel thrown away and replaced with a microservice fabric running on top of something like xen.

1
0
1

big-bang take: type-1 hypervisors are just the new microkernel, except they actually scale

2
0
0

anyway, it is totally possible to preserve the linux syscall ABI on such an architecture

1
0
0

@dysfun Xen provides useful abstractions that L4 does not :)

1
0
0

@dysfun (though i can feel aag dying inside when he inevitably reads this post)

0
0
0

@dysfun yeah, but what i mean is that it is relatively trivial to build the linux syscall ABI on top of Xen's channels, while it is much harder to build anything useful with L4, hince why L4 is pretty much always deployed as a microhypervisor

1
0
0

@dysfun Xen channels are basically ports, but with useful abstractions and without all of the crazy IDL nonsense that usually comes with ports.

0
0
0

@dysfun yeah, Mirage is a good example of why Xen is better to work with than traditional microkernels

0
0
0

@ariadne aren’t type 1 hypervisors conceptually similar to microkernels? A basic type 1 hypervisor schedules OSes across cores, allocates resources, and grants accesses to devices, and potentially provides a way of performing IPC between the VMs.

meanwhile a traditional microkernel does the same thing but one layer down. If I were to design one today, it would probably try to run as a hypervisor if available to have some sort of privilege separation between device drivers and the kernel

1
0
0

@ariadne i find windows’ way of doing syscalls a bit better because you can do userspace emulation much more easily since applications won’t just randomly hit an invalid (or dangerous) syscall

1
0
0

@ariadne the take sounded like they were fundamentally different sorry if i misunderstood

0
0
0

@charlotte sure, but we already have all these linux binaries which we can run today on any system which supports the linux syscall ABI ;)

1
0
1

@ariadne many of which can run on a different ABI by switching out the libc.so (which, good luck creating an ABI-compatible alternative to glibc)

1
0
0

@charlotte there's a lot of contractual details about the linux syscall ABI that doesn't really make this realistic

1
0
1

@ariadne i thought the bigger hurdle was the libc and it wouldn’t be particularly fast

1
0
0

@charlotte nah, the problem is that kernel-userspace details are encoded in the linux syscall ABI, which means if you switch out the libc, you might have different struct layouts, etc.

this is why NTDLL is a big deal in Windows land

0
0
1