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

61–70 of 196 posts

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

#61

Post by nuta »

0xTJ wrote: post #51
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…

Wow, I really like the implementation of that syscall. I've got my own toy OS project in C, for the M68k, and my `read` is "a little" less clean [0, 1]. [0]: https://gitlab.com/0xTJ/mosys/-/blob/master/src/vfs.c#L469 [1]: https://gitlab.com/0xTJ/mosys/-/blob/master/src/vfs.c#L907

Thanks! By the way, your MUTEX_WITH macro looks pretty interesting to me. I've never seen the idea.

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

#62

Post by monopoledance »

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/

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

#63

Post by abendstolz »

jacquesm wrote: post #60

Rewriting the Linux kernel in rust would be a rehash of why we ended up with Linux in the first place: rewriting an older OS from scratch. I would love to see a solid implementation of a real micro kernel based OS based on a message passing core in Rust to become a viable alternative to the now 50 year old Unix architecture. This would give us a possibility of some real progress on the security and process scheduling…

Just in case you don't know about it: https://redox-os.org/ could be interesting to you :)

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

#64

Post by nuta »

qwerty456127 wrote: post #57
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…

Even "rewriting Linux in Rust" is far from a waste if you make it run and if your code quality is good enough for others to join. If only you could write an entirely new (meant to be better, for some cases at least) kernel compatible with Linux hardware drivers - this would be not waste at all but in fact fantastic.

The most challenging point is, as others said, the lack of the compatibility with Linux Driver API. I believe it would be really hard to implement and keep following changes in Linux.

An idea in my mind is to use Kerla for virtualized environments like KVM where only limited device drivers are needed (virtio for example).

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

#65

Post by abendstolz »

tialaramex wrote: post #54
maleldil wrote: post #43

Earlier quoted context omitted.

Last I checked, one of the big problems was the Rust panics when you run out of memory, which is unacceptable in the kernel. Is there any progress on that?

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 not trying to be snarky here, I genuinely don't know and would like to.

If answering this is too complex, maybe you can point me in the right direction so I can ask the right questions to find answers myself? Thanks in any case!

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

#67

Post by pjmlp »

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?

Google has decided to go forward anyway.

Just like Android Linux compiles just fine with clang for the last five years or so, it now makes use of Rust.

https://source.android.com/setup/build/rust/building-rust-mo...

If upstream ever cares to support clang or Rust, that is another matter.

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

#68

Post by nivenkos »

kryptiskt wrote: post #39
nivenkos wrote: post #16

Post it when it's production ready. A big problem in the Rust ecosystem is the lack of continued work and support on libraries (understandably, since many are new and aren't commercially supported). For example, pyroute2 is still better for Linux admin that the equivalent Rust crates. Whilst the latter often fully support async, none of them cover all of the features of pyroute2 nor the easy-to-use API. Hopefully thi…

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

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

#69

Post by baktubi »

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…

Spending your time how you want to is never meaningless. Especially if you’re creating value in the world.

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

#70

Post by cormacrelf »

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…

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 allocator, handling the weird and wacky problem of initialising a data structure (for the heap) in such a way that if it fails, it fails without allocating but leaves some hint as to what went wrong.

Post reply on HN