←back to thread

Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

(github.com)
235 points Klasiaster | 2 comments | 15 Oct 24 12:01 UTC | HN request time: 0s | source
Show context
justmarc ◴[15 Oct 24 21:02 UTC] No.41853080[source]▶
I'm interested in these kind of kernels to run very high performance network/IO specific services on bare metal, with minimal system complexity/overheads and hopefully better (potential) stability and security.

The big concern I have however is hardware support, specifically networking hardware.

I think a very interesting approach would be to boot the machine with a FreeBSD or Linux kernel, just for the purposes of hardware as well as network support, and use a sort of Rust OS/abstraction layer for the rest, bypassing or simply not using the originally booted kernel for all user land specific stuff.

replies(4): >>41853111 #>>41853348 #>>41853724 #>>41855929 #
treeshateorcs ◴[15 Oct 24 21:05 UTC] No.41853111[source]▶
i might be wrong but if it's ABI compatible the same drivers will work?

p.s.: i was wrong

>While we prioritize compatibility, it is important to note that Asterinas does not, nor will it in the future, support the loading of Linux kernel modules.

https://asterinas.github.io/book/kernel/linux-compatibility....

replies(4): >>41853156 #>>41853164 #>>41853386 #>>41856891 #
yjftsjthsd-h ◴[15 Oct 24 21:38 UTC] No.41853386[source]▶
Linux doesn't even maintain ABI compatibility with itself, nobody else is going to manage it. The possibility that might work is there's a couple projects that maintain just enough API compatibility to reuse driver code from Linux (IIRC FreeBSD does this for some graphics drivers). But even then you're gambling with whether Linux decides to change implementation details one day, since internal APIs explicitly aren't stable.
replies(1): >>41853663 #
bcrl ◴[15 Oct 24 22:15 UTC] No.41853663[source]▶
The Linux kernel community takes ABI compatibility for userland very seriously. That developers in userland are frequently unwilling to understand issues surrounding ABI stability is not the fault of the Linux kernel.
replies(1): >>41853839 #
yjftsjthsd-h ◴[15 Oct 24 22:35 UTC] No.41853839{3}[source]▶
Oh sure, the user-space ABI is stable; I meant kernel-space. Although I realize now that I failed to write that explicitly.
replies(1): >>41854385 #
1. bcrl ◴[16 Oct 24 00:13 UTC] No.41854385{4}[source]▶
The past 30 years of the Linux kernel's evolution has proven that there is no need for a stable kernel ABI. That would make refactoring, adding new features and porting to new platforms exceedingly difficult. Pretty much all of the proprietary kernel modules have either become open source or been replaced by open source replacements. The Linux community doesn't need closed source kernel modules for VMWare anymore, and even Nvidia has finally given up on their closed source GPU drivers. Proprietary Linux kernel modules have no place in the modern world.
replies(1): >>41854526 #
2. vlovich123 ◴[16 Oct 24 00:34 UTC] No.41854526[source]▶
> even Nvidia has finally given up on their closed source GPU drivers.

lol. No. They just added a CPU and then offloaded all the closed source userspace driver code to it leaving behind the same dumb open sourceable kernel driver shim as before (ie instead of talking to userspace it talks to the GPU’s CPU).

> The past 30 years of the Linux kernel's evolution has proven that there is no need for a stable kernel ABI.

What the last 30 years have shown is that there is actually a need for it, otherwise DKMS wouldn’t be a thing. Heck, intel’s performance profiler can’t keep up with the kernel changes which means you get to pick running an up to date kernel or be able to use the open source out-of-tree kernel module. The fact that Linux is alone in this should make it clear it’s wrong. Heck Android even wrote their own HAL to try to make it possible to update the kernel on older devices. It’s an economics problem that the Linux kernel gets to pretend doesn’t exist but it’s a bad philosophical position. It’s possible to support refactoring and porting to new platforms while providing ABI compatibility and Linux is way past the point where it would even be a minor inconvenience - all the code has ossified quite a bit anyway.