> docker run -it --privileged --network=host --device=/dev/kvm -v $(pwd)/asterinas:/root/asterinas asterinas/asterinas:0.9.3
Is that the new generation of curl | bashism in action?
Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
121–130 of 234 posts
Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
#122Decades ago Linus Torvalds was asked in an interview if he feared Linux to be replaced by something new. His answer was that some day someone young and hungry would come along, but unless they liked writing device drivers Linux would be safe. This is all paraphrased from my memory, so take it with a grain of salt. I think the gist of it is still valid: Projects like Asterinas are interesting and have a place, but the…
I feel like there's a potentially large audience for a kernel that targets running in a VM. For a lot of workloads, a simple VM kernel could be a win.
this x1000
Provided you have virtio support you are ticking a lot of boxes already.
Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
#123Earlier quoted context omitted.
How is that different from Linux with all virtio drivers? (You can just not compile real hardware drivers)
I would imagine that virtualized device drivers would have a well-defined api and vastly simplified logic.
Shouldn't we start building hardware that have a builtin translation layer that makes them driveable by virtio drivers themselves? At least for the most capabilities?
Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
#124> docker run -it --privileged --network=host --device=/dev/kvm -v $(pwd)/asterinas:/root/asterinas asterinas/asterinas:0.9.3 Is that the new generation of curl | bashism in action?
Is the "--privileged" option ironic here? The project is very interesting, but it feels a bit pedantic, especially when emphasizing Rust's safety features while downplaying Linux. At the same time, it seems they're not fully applying those principles themselves, which makes it feel like they're not quite 'eating their own lunch'.
Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
#125Earlier quoted context omitted.
Otherwise is a decent language but what makes it difficult is the borrow semantics and lifetimes. Lifetimes are more complicated to get your head around. But then there's this Arc, Ref, Pinning and what not - how deep is that rabbit hole?
I always feel Arc is the admission that the borrow checker with different/overlapping lifetimes is too difficult, despite what many Rust developers - who liberally use Arc - claim.
It's not just difficult, sometimes it's impossible to statically know a lifetime of a value, so you must dynamically track it. Arc is one of such tools.
Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
#126Earlier quoted context omitted.
If you want truly high-performance networking, you can bypass the kernel altogether with DPDK. So you don't have to worry about alternative kernels for other tasks at all. On the downside, DPDK takes over the NIC entirely, removing the kernel from the equation, so if you need the kernel to see network traffic for some reason, it won't work for you. You can check out hardware support here: https://core.dpdk.org/suppor…
This was true a decade ago, with modern io_uring dpdk is probably an anti-pattern.
If you use io_uring, you're subject to vulnerabilities in kernel network stack which you have no control over.
Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
#127I looked into the architecture. It turns out to be monolithic with marketing[0]. Sure is a lot of text to say: We try to use unsafe as little as possible. Which is the minimum you'd expect anyways ¯\_(ツ)_/¯ 0. https://asterinas.github.io/book/kernel/the-framekernel-arch...
It's just what we used to call a "layered architecture".
Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
#128Earlier quoted context omitted.
Oh sure, the user-space ABI is stable; I meant kernel-space. Although I realize now that I failed to write that explicitly.
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, an…
It depends on your goals, but at least Torvalds believes driver availability is important and unstable ABI is known to hinder driver availability.
Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
#129Earlier quoted context omitted.
If you’re writing C and don’t track ownership of values, you’re in a world of hurt. Rust makes you do from day one what you could do in C but unless you have years of experience you think it isn’t necessary.
Okay, I think it is is more like Typescript. You hate it but one day you just write small JS program and convert it to Typescript to discover that static analysis alone had so many code paths revealed that would have resulted in uncaught errors and then you always feel very uncomfortable writing plain Javascript. But what about tools like valgrind in context of C?
Valgrind is great, especially if you write extensive tests and you actually run them through it regularly. And even then, it does not prove the absence of any kind of bugs. Safe rust has strong guarantees.
Re: Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
#130From the README: > Currently, Asterinas only supports x86-64 VMs. However, our aim for 2024 is to make Asterinas production-ready on x86-64 VMs. I'm confused.
They lack essential things for a kernel that could be used in production, viz. not kernel panicing during out-of-memory conditions, not an easy thing to retrofit when you have designed without consideration of it. It will probably take a bit more than 2 and a half months to rectify that.