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

171–180 of 234 posts

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

#171

Post by hnfong »

oefrha wrote: post #146
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?

Hardly different from downloading random binary installers and executing them. Or random source distributions and (sudo) make install. Or npm/pip/cargo/etc. install random packages. Before anyone mentions distros and package managers, as a former team member of a major package manager I can assure you we don’t vet shit beyond project notability, and new versions are accepted semi-automatically. We’ll yank something a…

> as a former team member of a major package manager I can assure you we don’t vet shit beyond project notability, and new versions are accepted semi-automatically

An example that illustrates this: https://lwn.net/Articles/22991/

(And wow, it's been 22 years already...?)

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

#172

Post by eyberg »

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.

This is a very large rationale for what we are building with https://nanos.org .

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

#173

Post by GoblinSlayer »

LinXitoW wrote: post #151
GoblinSlayer wrote: post #142

Earlier quoted context omitted.

Looking at the code, it consists of long chains of get().unwrap().to_mut().unwrap().get() noise. Looks like coping with library design than ownership tacking. Also why Result >? Isn't Result already Option by itself? I guess that's why you need get().unwrap().to_mut() to get a value from Result > from an average function call?

If I ask my repository (backed by an sql db) to get a user, there might be 3 different scenarios I'm interested in: - Technical problem (like connection problems) means I don't know what's in the db - No technical problem, but no user entry - No technical problem, and a user entry You need the Result for the technical problems, and the Option for whether there's a user entry or not.

Surely Result is supposed to hold both system errors and business errors.

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

#174

Post by thesuperbigfrog »

oniony wrote: post #169
thesuperbigfrog wrote: post #157

Earlier quoted context omitted.

>> Also why Result >? Isn't Result already Option by itself? No. I've written code that returns Result >. It was a wrapper for a server's query web API. The Result part determines whether the request succeeded and the response is valid. The Option part is because the parameter being queried might not exist. For example, if I ask the API for the current state of the user session with a given Session ID, but that Sessi…

Result is whether an operation returned an error or not. Option is whether you have a value or no value.

Exactly.

That is why a query that successfully returns no items can be represented as Ok(None).

A successful query with items returned would instead be Ok(Vec).

An error in the completing the query (for example, problem with the database), would be Err(DatabaseError) or Err(SomeOtherError).

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

#175

Post by thesuperbigfrog »

GoblinSlayer wrote: post #168
thesuperbigfrog wrote: post #157

Earlier quoted context omitted.

>> Also why Result >? Isn't Result already Option by itself? No. I've written code that returns Result >. It was a wrapper for a server's query web API. The Result part determines whether the request succeeded and the response is valid. The Option part is because the parameter being queried might not exist. For example, if I ask the API for the current state of the user session with a given Session ID, but that Sessi…

Presumably missing session is an alternative scenario and thus should be reported as an error, then you match and handle this error. Your design complicates the common scenario: in case of valid session you need double unwrap, cf File::open that could return Result > if file is not found.

>> Presumably missing session is an alternative scenario and thus should be reported as an error

But in this case, a query using an invalid session ID is not an error. It is asking for details about something that does not exist.

>> cf File::open that could return Result> if file is not found.

This type of query is not like File::open which gets a handle to a resource. Trying to get a handle to a resource that does not exist is an error.

This type of query is read-only and does not allocate any resources or prepare to do anything with the session.

It simplifies the control flow because it distinguishes between errors in completing a query versus the presence or absence of items returned from the query.

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

#176

Post by acomar »

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.

I've found the opposite. every time I attempt to subvert the borrow checker, I eventually discover that I'm attempting to write a bug.

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

#177

Post by afr0ck »

justmarc wrote: post #82
nijave wrote: post #40

Earlier quoted context omitted.

Couldn't you just boot the Linux kernel directly and launch a generic app as pid 1 instead of a full blown init system with a bunch of daemons? That's basically what you're getting with Docker containers and a shared kernel. AWS Lambda is doing something similar with dedicated kernels with Firecracker VMs

Yes, but I wanted to bypass having the complexity of the Linux kernel completely, too. Basically single app directly to network (the world) and as little as possible else in between.

Linux kernel is not complex. Most of the code runs lock-free. For example, the slab allocator in the kernel uses only a single double_cmpxhg instruction to allocate an object via kmalloc(). The algorithm scales to any number of CPUs and has NUMA awareness. Basically, the most concurrent, lowest allocation latency allocator you can get in the market, which also returns the best objects for the requesting process on big memory systems.

The complexity on the other hand is architectural and logical to achieve scale to hundreds of CPUs, maximise bandwidth and reduce latency as much as possible.

Any normal Rust kernel will either have issues scaling on multi-cores or use tax-heavy synchronisation primitives. The kernel RCU and lock-free algorithm took a long time to be discovered and become mature and optimised aggressively to cater for the complex modern computer architectures of out-of-order execution, pipelining, complex memory hierarchies (especially when it comes to caching) and NUMA.

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

#178

Post by delduca »

This is exactly what I was discussing with a friend who works on the kernel. I don’t think Rust should be supported; the kernel should remain in C. Instead, a completely new kernel in Rust should be created with API/ABI compatibility with the original kernel.

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

#179

Post by empath75 »

netbsdusers wrote: post #130
depressedpanda wrote: post #7

From 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. https://github.com/asterinas/asterinas/issues/669

https://github.com/rust-lang/rust/issues/48043

They've been working on it for a while so they can get rust into the linux kernel

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

#180

Post by bombela »

mcherm wrote: post #158
junon wrote: post #107

Earlier quoted context omitted.

Context: I'm writing a novel kernel in Rust. Lifetimes aren't bad, the learning curve is admittedly a bit high. Post-v1 rust significantly reduced the number of places you need them and a recent update allows you to elide them even more if memory serves. Arc isn't any different than other languages, not sure what you're referring to by ref but a reference is just a pointer with added semantic guarantees, and Pin isn'…

Would you not want to use Pin when sharing memory with a driver or extension written in a different language (eg: C)?

Pin is a pure compile time abstraction for a single problem: memory safety of self referential struct.

Pin leverages the type system to expose to the programmer receiving a pointer to a Pin'ned object, that this object has some pointer on itself (a self referencial struct). You better be mindful not to move this object to a different memory location unless you know for sure that it is safe to do so. The Pin abstraction makes it harder to forget; and easier to notice during code review; by forcing you to use the keyword unsafe for any operations on the pinned object that could move it around.

In C, there is no such way to warn the programmer besides documentation. It is up to the programmer to be very careful.

Post reply on HN