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

Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

github.com

Post reply on HN
Print view View original

81–90 of 196 posts

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#81

Post by abendstolz »

cormacrelf wrote: post #77
abendstolz wrote: post #72

Earlier quoted context omitted.

Oh, wow, I was under the impression that the error message would be stack only, no heap involved, but as Result is part of the std library and not of core, this totally makes sense. So for `Rust for Linux` they also need to implement a `Result-like` type that is stack only based to solve this issue, right? If so, cool, thanks, you just made my day by tickling my learning nerves! :)

It has nothing to do with Result, whatsoever. Result does not allocate. If you used a Result that way, you could certainly try to "gracefully" handle the allocation failure, but if you think it would be easy, you would be wrong. As Tialaramex said, you are probably just going to make the problem worse because it is very difficult to ensure you do not attempt to allocate during allocation-failure-recovery. Rustc doesn…

Thanks for the thorough explanation!

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#82

Post by gspr »

ls65536 wrote: post #56
gspr wrote: post #47

Earlier quoted context omitted.

A practical problem is that in order to gain the benefit of linking Rust and C code, one has to give up Rust's wonderful guarantees at the interface. So until islands of Rust meet up, these interact through a C ABI, and have to expose C-like behavior.

But you still get those guarantees and benefits in the Rust implementation itself, even if not at the interface (to non-Rust code). By a similar argument, a standalone Rust program "gives up" its guarantees whenever the process makes a call to libc or to the operating system (syscalls), but this isn't really a practical problem.

Sure, I agree. The point is that if the total corpus of Rust code is too isolated into too small islands, then the boundary effects of each island may eat up a lot of the benefit.

I still think the project is really cool and worthwhile.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#83

Post by fbanon »

nivenkos wrote: post #68
kryptiskt wrote: post #39

Earlier quoted context omitted.

> Post it when it's production ready. This is Hacker News, not Enterprise IT News.

I just meant that even big projects posted here in the past like the Headcrab debugger: https://github.com/headcrab-rs/headcrab have been seemingly abandoned now. Even Rocket https://github.com/SergioBenitez/Rocket seems to have greatly slowed development unfortunately.

Maybe those projects are considered "done".

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#84

Post by monopoledance »

nuta wrote: post #74
monopoledance wrote: post #62

Earlier quoted context omitted.

Thanks for checking in. Makes me happy to see your excitement for learning the inner workings of things. What do you think about other Rust OS projects like Redox? https://www.redox-os.org/

In addition to its huge contribution to OS development in Rust, as a microkernel enthusiast, it sounds exciting to writing a microkernel in Rust, in the "Everything is a URL" principle. Moreover, it can run a good-looking GUI on a real machines [1]! I know it's very hard to be realized. Aside from Redox, I'd mention Tock [2], an embedded operating system. It introduces a novel components isolation using Rust's power.…

Thanks for sharing!

I have to say, I feel a bit “dirty” carrying so much unused and legacy code around with Linux, so I like people trying to reinvent the wheel just for the pleasure of a fresh start. For the aesthetics. Even if it’s merely a fantasy and not replacing anything soon, realistically. They are also keeping OS development accessible to new generations of geeks. The unfriendliness of C, the gigantic codebase and seemingly distinct culture make the Linux kernel quite off putting, filtering possible engagement by unfortunate parameters IMO. Novel OS development in Rust takes away at least some of those barriers and some of the gained knowledge may be applicable with the Linux kernel later.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#85

Post by nix23 »

nuta wrote: post #41

Author here. I'm surprised to see my hobby project on Hacker News. I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long. That said, what I'd say here is that it's fun. Really fun. Implementing ABI compatibility requires you to und…

Really cool that you mentioned OSv on your github, really not enough eye's on it, i think.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#86

Post by skitter »

abendstolz wrote: post #65
tialaramex wrote: post #54

Earlier quoted context omitted.

Out of the box Rust doesn't provide any way to allocate heap memory, so, you can't run out if it. Your ordinary userspace apps use std (the standard library) which relies on the alloc crate, and that provides heap allocation which indeed panics if the allocation fails. Because it correctly guesses that your "clever" strategy to handle allocation failure actually isn't and will just triple fault anyway so it should cu…

Can you elaborate as to why "his isn't how you'd do things in userspace, but, this isn't userspace so fine" holds? Naive me - not a kernel dev at all - would argue that returning Result is always better, even for userspace because it would allow me to additionally log something or gracefully deal with this. Even if I don't want to deal with it, I could just `.unwrap()` or `.expect('my error message')` it. Note: I am…

AFAIK one other thing to note is that in Linux userspace, malloc (or fork) might succeed, but accessing the memory later can fail because of memory overcommit.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#87

Post by rtpg »

tialaramex wrote: post #71
abendstolz wrote: post #65

Earlier quoted context omitted.

Can you elaborate as to why "his isn't how you'd do things in userspace, but, this isn't userspace so fine" holds? Naive me - not a kernel dev at all - would argue that returning Result is always better, even for userspace because it would allow me to additionally log something or gracefully deal with this. Even if I don't want to deal with it, I could just `.unwrap()` or `.expect('my error message')` it. Note: I am…

> it would allow me to additionally log something If you don't have any memory your allocations are all failing. When you assemble the log message, the allocation needed to do that fails. Bang, double fault. Now, often people don't really mean they want allocations to be able to fail generally, they're just thinking about that code they wrote that reads an entire file into RAM. If it was a 100GB file that would be a…

People say that "well if allocations fail all bets are off" but can't you pre-allocate memory for error handling?

Like sit down, figure out all the things you'll want to do on an allocation failure, and once you have determined that you slice a little chunk of memory when you start your app (and maybe _that_ fails and you can't do anything). and when you hit a failure you do your think, then tear stuff down.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#88

Post by ensiferum »

tialaramex wrote: post #71
abendstolz wrote: post #65

Earlier quoted context omitted.

Can you elaborate as to why "his isn't how you'd do things in userspace, but, this isn't userspace so fine" holds? Naive me - not a kernel dev at all - would argue that returning Result is always better, even for userspace because it would allow me to additionally log something or gracefully deal with this. Even if I don't want to deal with it, I could just `.unwrap()` or `.expect('my error message')` it. Note: I am…

> it would allow me to additionally log something If you don't have any memory your allocations are all failing. When you assemble the log message, the allocation needed to do that fails. Bang, double fault. Now, often people don't really mean they want allocations to be able to fail generally, they're just thinking about that code they wrote that reads an entire file into RAM. If it was a 100GB file that would be a…

What if the failed allocation came from a different allocator/heap than from where the allocations for string logging came from?

In general Don't assume anything about your global process state just because one allocator fails.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#89

Post by hnlmorg »

rakoo wrote: post #44
nuta wrote: post #41

Author here. I'm surprised to see my hobby project on Hacker News. I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long. That said, what I'd say here is that it's fun. Really fun. Implementing ABI compatibility requires you to und…

> I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long. Considering that this is exactly how Linux was born (just a hobby project for fun), I wouldn't assume so fast that it's useless. Moreover, you don't need to justify yourself…

I don't see why we need to pretend that every hobby has the potential for greatness. Being a hobby is a good enough end to itself.

In fact in this instance I think it's a little disingenuous to quote Linux and say it could happen again. The industry is totally different now. There's much more competition than there was when Linux was released and that competition is much more mature too. Plus the bar for a production-quality kernel is a lot higher than it was when Linux was released.

Re: Kerla: Monolithic kernel in Rust, aiming for Linux ABI compatibility

#90

Post by __s »

nivenkos wrote: post #68
kryptiskt wrote: post #39

Earlier quoted context omitted.

> Post it when it's production ready. This is Hacker News, not Enterprise IT News.

I just meant that even big projects posted here in the past like the Headcrab debugger: https://github.com/headcrab-rs/headcrab have been seemingly abandoned now. Even Rocket https://github.com/SergioBenitez/Rocket seems to have greatly slowed development unfortunately.

Nowadays the Rust http libraries to use are warp or axum (but Rocket works as is)

https://github.com/seanmonstar/warp

https://github.com/tokio-rs/axum

re headcrab, https://github.com/headcrab-rs/headcrab/issues/132

Post reply on HN