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

101–110 of 196 posts

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

#101

Post by bcantrill »

panick21_ wrote: post #99
surajrmal wrote: post #97

Earlier quoted context omitted.

Is Hubris targeted at BMCs? Or is something different?

I think its an FPGA with a costume Open-Source Titan chip on it (RISC-V). It is not really a traditional BMC, its more like a service processor that does secure boot and gets you in the OS. It does a few other things but I think they really want it to have minimum functionality. This is a great talk about what they do and why: https://www.youtube.com/watch?v=vvZA9n3e5pc

This is a very reasonable inference, as it absolutely was when I gave that talk. ;) Very shortly after that talk, however, we came to the realization that the OpenTitan was not going to be what we needed when we needed it, and moved to a Cortex M7-based microcontroller for our service processor (and a separate M33-based microcontroller for our root of trust); Hubris is the operating system that runs on those two MCUs.

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

#102

Post by bitcoinmoney »

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…

How long did it take you to write this?

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

#103

Post by schuyler2d »

abendstolz wrote: post #75
tialaramex wrote: post #71

Earlier quoted context omitted.

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

Result is part of core [0]. Result data and/or errors can be stack-only data. The parent was just saying that many people that say they want to guard against out-of-memory issues aren't cognizant of just how difficult that is.

Add to that that several operating systems will lie about whether you're out of memory, so the 'error' or failure will often not be on the Result() value but come in a SIGKILL instead, it's just adding complexity.

People that are actually worried about it and no how to deal with it, will be coding with a different style and can use the alloc library where/when they need to. (at least when it gets stabilized in Rust)

[0] https://doc.rust-lang.org/core/result/

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

#104

Post by ibraheemdev »

__s wrote: post #90
nivenkos wrote: post #68

Earlier quoted context omitted.

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

> Nowadays the Rust http libraries to use are warp or axum

Warp and axum are certainly not the only choices, and saying they are the best choices is a matter of opinion. Actix-web, rocket, tide, warp, axum are all great web frameworks.

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

#105

Post by abendstolz »

schuyler2d wrote: post #103
abendstolz wrote: post #75

Earlier quoted context omitted.

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

Result is part of core [0]. Result data and/or errors can be stack-only data. The parent was just saying that many people that say they want to guard against out-of-memory issues aren't cognizant of just how difficult that is. Add to that that several operating systems will lie about whether you're out of memory, so the 'error' or failure will often not be on the Result() value but come in a SIGKILL instead, it's jus…

Thanks for correcting my error.

I've never checked core before, so I did when checking up for this discussion.

I somehow missed Result. Silly me didn't search on that page, but ofc I found it on std

https://doc.rust-lang.org/std/result/index.html

Also thanks for clarifying that values of Result can be stack-only!

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

#107

Post by panick21_ »

bcantrill wrote: post #101
panick21_ wrote: post #99

Earlier quoted context omitted.

I think its an FPGA with a costume Open-Source Titan chip on it (RISC-V). It is not really a traditional BMC, its more like a service processor that does secure boot and gets you in the OS. It does a few other things but I think they really want it to have minimum functionality. This is a great talk about what they do and why: https://www.youtube.com/watch?v=vvZA9n3e5pc

This is a very reasonable inference, as it absolutely was when I gave that talk. ;) Very shortly after that talk, however, we came to the realization that the OpenTitan was not going to be what we needed when we needed it, and moved to a Cortex M7-based microcontroller for our service processor (and a separate M33-based microcontroller for our root of trust); Hubris is the operating system that runs on those two MCUs…

Not that it matters all that much, but why a Cortex when you can get RISC-V chips form SiFive (or whoever) that do about the same stuff?

Does that mean the product will not have an FPGA? I kind of liked that idea of updating the hardware.

P.S: Twitter spaces about the history of computing are really fun. Love to hear more about all the dead computer companies you researched. There is not enough content about computer history out there.

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

#108

Post by jstarks »

pjmlp wrote: post #67
geewee wrote: post #32

Earlier quoted context omitted.

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.

Unless I'm missing something, that link refers to building Android user-mode components in Rust, not kernel components in Rust.

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

#109

Post by pornel »

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.

Yes, gradual replacement is easier and more practical for large projects. However, typical C APIs and idioms are different from idiomatic Rust. Rust uses more type-system features, generics, iterators, RAII, and prefers tree-like data structures and far fewer pointers (no linked lists!).

C rewritten in Rust is still very C-like, and requires refactorings that you can't do until it's all Rust.

BTW: There are two GCC-based Rust implementations in the works, so compatibility with exotic platforms is going to be solved.

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

#110

Post by jedimastert »

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…

Aside from "rewrite in rust" debate that I was unaware of, there seems to be this pervasive attitude among the HN hivemind that the end-goal for all projects, side- or main-, is "launch", and therefore needs a market analysis to decide the "worth" of such an idea, and it ends up being rather silly.

For example, I've written a Mandelbrot visualizer so many times I've lost count. Not because the world needs another poorly written or optimized rainbow-ladybug-simulator, but because it serves as a slightly-non-trivial hello-world. For example, it's the first end-to-end thing I made in Common Lisp. https://git.sr.ht/~amtunlimited/mandelbrot-plot

Post reply on HN