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

111–120 of 234 posts

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

#111

Post by dathinab »

nickpsecurity wrote: post #72
ackfoobar wrote: post #63

Earlier quoted context omitted.

> Hohndel clarified that by "clueless", Torvalds was referring to his younger self As the saying goes "We do this not because it is easy, but because we thought it would be easy." Occasionally these are starts of great things.

Sometimes, we do such things because it’s hard. We enjoy the challenge. Those that succeed are glad to make it, too.

but most times, even in such cases, people underestimate or not estimate at all the "hard task they do as a challenge" it's kinda part of the whole thing

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

#112

Post by mdhb »

lifty wrote: post #94
mdhb wrote: post #89

Earlier quoted context omitted.

Also this mysterious new Fuchsia OS from Google is also shooting for full Linux compatibility and is about to show up in Android, I think this is a much more realistic path of the next generation of operating systems that have a real chance to replace Linux but who knows what their actual plans are here at the moment but I don’t believe for a moment that that project is dead in any way.

Can you give more details about it being used in Android? I thought they started using it in some small devices like nest but haven’t heard anything about Android

It’s about to turn up inside Android running in a VM [1] but it was less clear exactly for what purpose.

My theory is that this is essentially a long term project to bring the core of Chrome OS and Android to rely on Fuschia for its core which gives them syscall level compatibility with what they both use at the moment and that they would both essentially sit as products on top of that.

This is essentially the exact strategy they used if I remember correctly with the Nest devices where they swapped out the core and left the product on top entirely unchanged. Beyond that in a longer term scenario we might also just see a Fuchsia OS as a combined mobile / desktop workstation setup and I think part of that is also why we are seeing ChromeOS starting to take a dependency on Android’s networking stack as well right now.

[1] https://www.androidauthority.com/microfuchsia-on-android-345...

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

#113

Post by eptcyka »

wiz21c wrote: post #101

> Linux-compatible ABI Does it mean it can re-use the drivers written for hardware to run with linux ?

No. The drivers in Linux are kernel modules, most often in-tree - meaning that the source for the drivers is built along the rest of the kernel source code. Most hardware drivers depend on various common kernel structures that change often - when they do, the source for drivers is fixed practically in the same git branch. There is no driver ABI to speak of.

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

#114

Post by dathinab »

treeshateorcs wrote: post #22
justmarc wrote: post #21

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 h…

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

in general the ABI is kerneluser space while the ABI (and potentially even API) on the inside (i.e. for drivers) can change with every kernel version (part of why it's so important to maintain drivers in-tree)

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

#115

Post by guenthert »

cgh wrote: post #34
jauntywundrkind wrote: post #33

Earlier quoted context omitted.

This was true a decade ago, with modern io_uring dpdk is probably an anti-pattern.

Interesting, it's been awhile since I looked at this stuff so I did a little searching and found this: https://www.diva-portal.org/smash/get/diva2:1789103/FULLTEXT... Their conclusion is io_uring is still slower but not by much, and future improvements may make the difference negligible. So you're right, at least in part. Given the tradeoffs, DPDK may not be worth it anymore.

"io_uring had a maximum throughput of 5.0 Gbit/s "

Wut? More than 10 years ago, a cheap beige box could saturated a 1Gbps link with a kernel as it came from e.g. Debian w/o special tuning. A somewhat more expensive box could get a good share of a 10Gbps link (using Jumbo frames), so these new results are, er, somewhat underwhelming.

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

#116

Post by dathinab »

exabrial wrote: post #58

I think this looks incredible. Like how does one create a compatible abi _for all of linux_??? Wow! > utilize the more productive Rust programming language Nitpick: it’s 2024 and these ‘more productive’ comparisons are silly, completely unscientific, And a bit of a red flag for your project: The most productive language for a developer is the one they understand what is happening one layer below the level of abstract…

Idk. Asahi Linux GPU driver breaks all "common sense" of "how fast a reliable usable feature rich driver" was produced by a small 3rd party team.

The company I work for has both rust and python projects (through partially pre "reasonable python type linting" using mypy and co.) and the general consensus there is "overall" rust is noticeable more productive (and stable in usage/reliable), especially if you have code which changes a lot.

A company I worked previous for had used rust in the very early days (around 1.0 days) and had one of this "let's throw up a huge prototype code base in a matter of days and then rewrite it later" (basically 90% of code had huge tech dept). But that code base stuck around way longer then intended, caused way less issues then expected. I had to maintain it a bit and in my experience with similar code in Python and Js (and a bit Jave) I expected it to be very painful but surprisingly it wasn't, like at all.

Similar comparing my experience massive time wastes due to having to debug soundness/UB issues in Rust, with experiences in C/C++ it's again way more productive.

So as long as you don't do bad stuff like over obsessing with the type system everything in my experience tells me using Rust is more productive (for many tasks, definitely not all task, there are some really grate frameworks doing a ton of work for you in some languages against which the rust ecosystem atm. can't compete).

---

> Most productive language for a developer is the one they understand what is happening one layer below the level of abstraction they are working with.

I strongly disagree, the most productive language is the one where the developer doesn't have to care much about what happens in a layer below in most cases. At least as long as you don't want obsess over micro optimizations not being worth the time and opportunity cost they come with for most companies/use cases.

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

#117

Post by sshine »

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"

LLMs are notoriously bad at improvising device drivers in no-std Rust.

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

#118

Post by GoblinSlayer »

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…

Just ask an AI to riir linux drivers. Anybody tried it?

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

#119

Post by jeroenhd »

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.

Lifetime tracking and ownership are very difficult. That's why languages like C and C++ don't do it. It's also why those languages needs tons of extra validation steps and analysis tools to prevent bugs.

Arc is nothing more than reference counting. C++ can do that too, and I'm sure there are C libraries for it. That's not an admission of anything, it's actually solving the problem rather than ignoring it and hoping it doesn't crash your program in fun and unexpected ways.

Using Arc also comes with a performance hit because validation needs to be done at runtime. You can go back to the faster C/C++ style data exchange by wrapping your code in unsafe {} blocks, though, but the risks of memory corruption, concurrent access, and using deallocated memory are on you if you do it, and those are generally the whole reason people pick Rust over C++ in the first place.

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

#120

Post by BodyCulture »

dathinab wrote: post #111
nickpsecurity wrote: post #72

Earlier quoted context omitted.

Sometimes, we do such things because it’s hard. We enjoy the challenge. Those that succeed are glad to make it, too.

but most times, even in such cases, people underestimate or not estimate at all the "hard task they do as a challenge" it's kinda part of the whole thing

Sometimes we just don’t know if a person that started something did know how hard it would be or not. Sometimes it is not possible to know how hard things can be or not.

Generally this is a very interesting question hat could be discussed in a very long thread, but still the reader will not get any value from it.

Post reply on HN