21–30 of 196 posts
The only technical problem I can think of is that Rust may not be available for all CPU architectures Linux supports, but this is just speculation on my part having done no research on the matter.
Earlier quoted context omitted.
That’s very cool! Could you share some details on how to set it up for oneself with AWS Firecracker the same way that this demo was set up? Also, as owner of the instances are you able to see what commands people are running? First thing I did was to type hello, and it said hello world to me :)
I'm not the project author, maybe you can ask via e-mail, see https://seiya.me/
Very cool! I think a killer feature would be to emulate the Linux kernel device driver model such that existing C driver modules could be used with Kerla. Further, borrow (no pun intended!) the Linux device driver Rust wrappers from the Rust for Linux kernel project to then enable writing Linux device drivers in Rust. The question is whether emulating the Linux device driver model (by which I kind of mean mimicking t…
Heck, it'd probably be easier to emulate the Windows driver architecture - at least those have proper ABI compat.
Post it when it's production ready. A big problem in the Rust ecosystem is the lack of continued work and support on libraries (understandably, since many are new and aren't commercially supported). For example, pyroute2 is still better for Linux admin that the equivalent Rust crates. Whilst the latter often fully support async, none of them cover all of the features of pyroute2 nor the easy-to-use API. Hopefully thi…
A star has been born. A Linux alternative needs to be compatible with Linux binaries and also support modern architectures. If you want Linux to survive, it needs to be re-written from scratch, optimised in Rust and compatible with the existing Linux binaries or drivers. This project might have a chance. From: [0] > TL;DR: I'm writing a Linux clone in Rust just for fun. It does NOT aim to replace the Linux kernel. A…
Very cool! I think a killer feature would be to emulate the Linux kernel device driver model such that existing C driver modules could be used with Kerla. Further, borrow (no pun intended!) the Linux device driver Rust wrappers from the Rust for Linux kernel project to then enable writing Linux device drivers in Rust. The question is whether emulating the Linux device driver model (by which I kind of mean mimicking t…
The kernel has (deliberately) never had a simple or stable driver ABI, so I think this is potentially a huge task. And then you've also left a C-based attack surface in place.
I'm not sure what the minimal set is if you decide to only support 2021-era hardware. PCIe+SATA+framebuffer+USBhost+USBHID?
For each piece of software, there just be a version in Rust, and that version must advertise it's rustiness
Very cool! I think a killer feature would be to emulate the Linux kernel device driver model such that existing C driver modules could be used with Kerla. Further, borrow (no pun intended!) the Linux device driver Rust wrappers from the Rust for Linux kernel project to then enable writing Linux device drivers in Rust. The question is whether emulating the Linux device driver model (by which I kind of mean mimicking t…
Maybe starting with the rumpkernel interface is easier and one could already use some of the NetBSD drivers: https://en.wikipedia.org/wiki/Rump_kernel
While I completely agree that NetBSD's Rump kernel would be a great way to go (I've played with it in the past and quite like it!) I do wish there was a similar initiative bound to the Linux kernel.
The closest I've seen is Octavian Purdila's Linux-Kernel-Library project: https://lkml.org/lkml/2015/11/3/706
Not sure how far they've come though. Perhaps Kerla could be a prime mover for them ?
Earlier quoted context omitted.
The type of software makes the difference - does it process untrusted input, maybe even over the network? This here is a kernel including a memory-safe TCP/IP stack ( https://github.com/smoltcp-rs/smoltcp/ ), and not having it crash or be full of security vulnerabilities due to preventable memory corruption is a quality beyond personal language preferences.
It is possible to overstate a valid case until it becomes meaningless... are modern OS IP stacks written in C really 'crash'ing or 'full of security vulnerabilities'? No.
This may be a naive question, but I cannot help but wonder: As C and Rust aim to be link-compatible, wouldn't it be easier to gradually replace parts of the Linux kernel with Rust code? The only technical problem I can think of is that Rust may not be available for all CPU architectures Linux supports, but this is just speculation on my part having done no research on the matter.
The limitation of that approach is that all internal interfaces (which includes most data structures) have to be C-compatible. You can get much of the safety benefits of Rust, but lose a lot of Rust's ergonomics.