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

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.


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

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

@ariadne it's sad we have to call these hot takes instead of just... standard reality by now

i see rust as a decent compromise so my existing linux systems can stop running unproven code, until i get into os/exokernel dev hardcore and can undo the damage unix did to us

@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

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

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

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

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

@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

@ariadne yep! Qnx had this great POSIX layer on top of their microkernel without much of an overhead. It was even included in their floppy demo. Linux ABI is probably an order of magnitude larger, but certainly doable.

@ariadne microkernels can scale. at least SeL4 can scale. Oh you wanted linux? lol

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

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

@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

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

@ariadne i quite liked something i saw years ago where they used that microkernel thing in ocaml to build a tls layer such that the bulk of the work was done in a vm that only ever had access to the session key

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

@ariadne tbf though, SeL4 is really nice if everything is already built for it properly and there's huge convenience from running in userspace

@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

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

Sign in to participate in the conversation
Treehouse Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!