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

71–80 of 196 posts

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

#71

Post by tialaramex »

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…

> 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 bad idea. But the best answer is: Guard the allocation you're actually worried about, don't ladle this into the fast path everybody has to deal with on every allocation.

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

#72

Post by abendstolz »

cormacrelf wrote: post #70
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…

Tialaramex answered this in their post already, and you almost answered the question yourself: > I could just .unwrap() or .expect('my error message') it. Panicking can allocate. Allocating can fail. Failing can panic. Panicking can allocate. Allocating can fail. You can bite yourself in the ass like a real Ourobouros. IMO, a prerequisite to using fallible allocation APIs should be attempting to write your own alloca…

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! :)

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

#73

Post by krater23 »

roblabla wrote: post #23
fork-bomber wrote: post #15

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…

Linux drivers don't have a fixed ABI (or even API), making such a feat somewhere between hard and impossible. You'd have to constantly play catch up with the latest kernel refactorings, which would require a tremendous amount of engineering effort. Heck, it'd probably be easier to emulate the Windows driver architecture - at least those have proper ABI compat.

>Heck, it'd probably be easier to emulate the Windows driver architecture - at least those have proper ABI compat.

And better drivers.

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

#74

Post by nuta »

monopoledance wrote: post #62
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…

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. I believe this field is where Rust shines and am looking forward to seeing it in production.

[1]: https://www.redox-os.org/screens/ [2]: https://www.tockos.org

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

#75

Post by abendstolz »

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…

Mhm, thanks.

It never occurred to me (being in non-embedded land) that returning an enum as the error or a &'static str instead of a heap structure like String, could also fail.

Seeing that Result isn't part of core, but of std, this makes sense.

Just to tickle my nerve though: theoretically speaking, with your example, it would work, right?

I couldn't allocate 100GB (because OOM or not even enough RAM to begin with) but it could be that the system can allocate the needed memory for error message just fine.

Very interesting.

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

#76

Post by phendrenad2 »

krylon wrote: post #21

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 Linux kernel is massive, so writing any part of it in Rust is an enormous undertaking. Even a few functions at a time, we're talking decades.

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

#77

Post by cormacrelf »

abendstolz wrote: post #72
cormacrelf wrote: post #70

Earlier quoted context omitted.

Tialaramex answered this in their post already, and you almost answered the question yourself: > I could just .unwrap() or .expect('my error message') it. Panicking can allocate. Allocating can fail. Failing can panic. Panicking can allocate. Allocating can fail. You can bite yourself in the ass like a real Ourobouros. IMO, a prerequisite to using fallible allocation APIs should be attempting to write your own alloca…

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't and can't really check this for you.

It actually has to do with `panic!(...)`. When you use `unwrap()`/`expect("...")`, you use the panic macro under the hood; parts of the panicking infrastructure use a boxed trait object which could contain a static string or formatted String or anything else really. The box can allocate if it is not a ZST. I believe the alloc crate's default handler tries to avoid this kind of thing, so that it can't fail to allocate AGAIN in the failure-handling routine. It will likely do a better job than you could.

This is a live issue at the moment, so to go into any more detail I'd have to read a bunch of recent Rust issues/PRs.

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

#78

Post by ericbarrett »

geewee wrote: post #32
wongarsu wrote: post #30

Earlier quoted context omitted.

That's what may happen with the Linux kernel over time, now that it allows parts written in Rust. 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.

I don't think that the Linux kernel has decided (yet) to allow rust code into the kernel proper, has it?

An LWN article about Rust in Linux that's very relevant to this discussion: https://lwn.net/Articles/829858/

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

#79

Post by bluejekyll »

abendstolz wrote: post #72
cormacrelf wrote: post #70

Earlier quoted context omitted.

Tialaramex answered this in their post already, and you almost answered the question yourself: > I could just .unwrap() or .expect('my error message') it. Panicking can allocate. Allocating can fail. Failing can panic. Panicking can allocate. Allocating can fail. You can bite yourself in the ass like a real Ourobouros. IMO, a prerequisite to using fallible allocation APIs should be attempting to write your own alloca…

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! :)

Result already is “stack” based, or sized. It also already exists in core: https://doc.rust-lang.org/core/result/index.html

The Error type currently isn’t in core, but for other reasons, that just got resolved: https://twitter.com/bascule/status/1452029363197784071?s=21

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

#80

Post by panick21_ »

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

There are more good efforts, the BeTrusted guys are working on Xous, its a microkernel for a phone like device called the Precurser.

https://github.com/betrusted-io/xous-core

As a embedded service processor OS for a big server rack, Oxide Computer is working on 'HubrisOS'. They seem to have not released it yet, but that will be open sourced.

https://github.com/oxidecomputer

Those are two efforts where I know real resources are going into.

Post reply on HN