Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

131–140 of 234 posts

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

#131

Post by baq »

wg0 wrote: post #110
baq wrote: post #93

Earlier 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?

You probably should run your rust programs through valgrind regardless. Rust is safer than C, but any unsafe code drops you to approximately C level of safety and any C FFI calls are obviously outside of rust's control or responsibility.

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

#132

Post by prmoustache »

wslh wrote: post #124
prmoustache wrote: post #121

> 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'.

A bit below in the github readme there is a link to the handbook where they explain how to build and run the project using cargo:

https://asterinas.github.io/book/osdk/guide/run-project.html

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

#133

Post by sylware »

Linux is mostly a decades long maintained repository of real hardware programing code, and written in mostly simple "kernel" 'C', not some ultra complex syntax language (unfortunately, it has been tied to compiler specific extensions or "modern C" tantrums, _generic for instance).

Have a look at AMD GPU driver. Massive, and full of 'stabilization/work around' code... happening all the time, for years.

I guess, the real "first thing first" is to design hardware, performant hardware on latest silicon process , with a, as simple as possible, modern, standard and stable hardware programing interface. Because, for many types of hardware, 'now we know how to do it properly' (command hardware ring buffers usually, or a good compromise for modern CPU architecture, like RISC-V).

Another angle of "cleanup", I guess it would be the removal of many of the C compiler extension (or "modern C") tantrums from linux, or at least proper alternatives with not-inline assembly to allow small and alternative compilers to step in.

Personally, I tend to write rv64 assembly (which I interpret on x86_64), but for the userland. If I code C, I push towards mostly "simple and plain C99".

The more I think about it, the more I get the following coming to my mind: 'hardware with simple standard interfaces' and standard assembly for the kernel.

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

#134

Post by artemonster »

sylware wrote: post #133

Linux is mostly a decades long maintained repository of real hardware programing code, and written in mostly simple "kernel" 'C', not some ultra complex syntax language (unfortunately, it has been tied to compiler specific extensions or "modern C" tantrums, _generic for instance). Have a look at AMD GPU driver. Massive, and full of 'stabilization/work around' code... happening all the time, for years. I guess, the re…

Huh? What is this nonsense?? Are you suggesting that you like to write practical-oriented, simple and working solutions instead of yak shaving half a day at perfecting ridiculous type signatures, removing „unsafe“ code and satisfying borrow checker? Proposterous! /s

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

#135

Post by netbsdusers »

Galanwe wrote: post #90
KingOfCoders wrote: post #88

Earlier quoted context omitted.

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 that the borrow checker is too difficult, it's that it's too limiting. The _static_ borrow checker can only check what is _statically_ verifiable, which is but a subset of valid programs. There are few things more frustrating than doing something you know is correct, but that you cannot express in your language.

For kernels (and I suspect database engines might be added to the list, since they seem to have similar requirements to be both scalable and deal with massive amounts of shared state, but I'm not overly familiar with them) is where it gets particularly difficult.

Several kernels for example use type-stable memory, memory that is guaranteed to only hold objects of a particular type, though perhaps only providing that guarantee for as long as you hold an RCU read-lock (this is the case in Linux with SLAB_TYPESAFE_BY_RCU). It is possible in some cases to be able to safely deal with references to objects where the "lifetime" of the referent has ended, but where by dint of it being guaranteed to be the same type of object, you can still do what you want to do.

This comes in handy when you have a problem that commonly appears in kernels where you need to invert a typical lock ordering (a classic case is that the page fault codepath might want to lock, say, VM object then page queue, but the page-replacement codepath will want to lock page-queue then VM object.)

Unfortunately it's hard to think of how the preconditions for these tricks could be formally expressed.

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

#136

Post by Y_Y »

m463 wrote: post #80
loeg wrote: post #46

Earlier quoted context omitted.

More recently, in a similar vein: > Torvalds seemed optimistic that "some clueless young person will decide 'how hard can it be?'" and start their own operating system in Rust or some other language. If they keep at it "for many, many decades", they may get somewhere; "I am looking forward to seeing that". Hohndel clarified that by "clueless", Torvalds was referring to his younger self; "Oh, absolutely, yeah, you hav…

"You are enthusiastic and write kernel device drivers in rust. Write a device driver for an Intel i350 4 Port gigabit ethernet controller"

Claude Sonnet 3.5 seemed happy enough to do it, and the start looked promising

     Absolutely! Let's dive into writing a device driver for the Intel i350 4 Port Gigabit Ethernet Controller using Rust. This is an exciting project that combines low-level hardware interaction with the safety and performance benefits of Rust. I'll create a basic structure for our driver, focusing on the key components needed to interact with the device.

    #![no_std]
    #![feature(abi_x86_interrupt)]    
    ...
but I'm not qualified to judge the quality from eyeballing and I'm certainly not going to go to the trouble of trying to test it.

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

#138

Post by lmm »

yjftsjthsd-h wrote: post #75
linsomniac wrote: post #68

Earlier quoted context omitted.

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.

How is that different from Linux with all virtio drivers? (You can just not compile real hardware drivers)

The point is it would be better than Linux in whatever way that was the reason you were writing it, but you don't have to write hundreds of different device drivers to make your cool new kernel usable.

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

#139

Post by lmm »

linsomniac wrote: post #68
weinzierl wrote: post #44

Decades 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.

Those workloads would probably be better off as unikernels that can run directly on the VM, avoiding the question of which kernel to use entirely.

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

#140

Post by lmm »

KingOfCoders wrote: post #88
wg0 wrote: post #76

Earlier 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.

If tracking lifetimes is simple 90% of the time and complex 10% of the time, maybe a tool that lets you have them automatically managed (with some runtime overhead) that 10% of the time is the right way forward.
Post reply on HN