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

Moss: a Rust Linux-compatible kernel in 26,000 lines of code

github.com

Post reply on HN
Print view View original

1–10 of 163 posts

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#2

Post by hexagonal-sun »

Hello!

For the past 8 months, or so, I've been working on a project to create a Linux-compatible kernel in nothing but Rust and assembly. I finally feel as though I have enough written that I'd like to share it with the community!

I'm currently targeting the ARM64 arch, as that's what I know best. It runs on qemu as well as various dev boards that I've got lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has enough implemented to run most BusyBox commands on the console.

Major things that are missing at the moment: decent FS driver (only fat32 RO at the moment), and no networking support.

More info is on the github readme.

https://github.com/hexagonal-sun/moss

Comments & contributions welcome!

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#3

Post by bramadityaw »

hexagonal-sun wrote: post #2

Hello! For the past 8 months, or so, I've been working on a project to create a Linux-compatible kernel in nothing but Rust and assembly. I finally feel as though I have enough written that I'd like to share it with the community! I'm currently targeting the ARM64 arch, as that's what I know best. It runs on qemu as well as various dev boards that I've got lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has…

shouldn't this be a ShowHN?

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#4

Post by Rochus »

hexagonal-sun wrote: post #2

Hello! For the past 8 months, or so, I've been working on a project to create a Linux-compatible kernel in nothing but Rust and assembly. I finally feel as though I have enough written that I'd like to share it with the community! I'm currently targeting the ARM64 arch, as that's what I know best. It runs on qemu as well as various dev boards that I've got lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has…

Cool project, congrats. I like the idea with libkernel which makes debugging easier before going to "hardware". It's like the advantages of a microkernel achievable in a monolithic kernel, without the huge size of LKL, UML or rump kernels. Isn't Rust async/awat depending on runtime and OS features? Using it in the kernel sounds like an complex bootstrap challenge.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#5

Post by kaoD »

Rochus wrote: post #4
hexagonal-sun wrote: post #2

Hello! For the past 8 months, or so, I've been working on a project to create a Linux-compatible kernel in nothing but Rust and assembly. I finally feel as though I have enough written that I'd like to share it with the community! I'm currently targeting the ARM64 arch, as that's what I know best. It runs on qemu as well as various dev boards that I've got lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has…

Cool project, congrats. I like the idea with libkernel which makes debugging easier before going to "hardware". It's like the advantages of a microkernel achievable in a monolithic kernel, without the huge size of LKL, UML or rump kernels. Isn't Rust async/awat depending on runtime and OS features? Using it in the kernel sounds like an complex bootstrap challenge.

Rust's async-await is executor-agnostic and runs entirely in userspace. It is just syntax-sugar for Futures as state machines, where "await points" are your states.

An executor (I think this is what you meant by runtime) is nothing special and doesn't need to be tied to OS features at all. You can poll and run futures in a single thread. It's just something that holds and runs futures to completion.

Not very different from an OS scheduler, except it is cooperative instead of preemptive. It's a drop in the ocean of kernel complexities.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#6

Post by IshKebab »

hexagonal-sun wrote: post #2

Hello! For the past 8 months, or so, I've been working on a project to create a Linux-compatible kernel in nothing but Rust and assembly. I finally feel as though I have enough written that I'd like to share it with the community! I'm currently targeting the ARM64 arch, as that's what I know best. It runs on qemu as well as various dev boards that I've got lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has…

Impressive work! Do you have any goals, other than learning and having fun?

Also how does it's design compare with Redox and Asterinas?

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#7

Post by rcxdude »

kaoD wrote: post #5
Rochus wrote: post #4

Earlier quoted context omitted.

Cool project, congrats. I like the idea with libkernel which makes debugging easier before going to "hardware". It's like the advantages of a microkernel achievable in a monolithic kernel, without the huge size of LKL, UML or rump kernels. Isn't Rust async/awat depending on runtime and OS features? Using it in the kernel sounds like an complex bootstrap challenge.

Rust's async-await is executor-agnostic and runs entirely in userspace. It is just syntax-sugar for Futures as state machines, where "await points" are your states. An executor (I think this is what you meant by runtime) is nothing special and doesn't need to be tied to OS features at all. You can poll and run futures in a single thread. It's just something that holds and runs futures to completion. Not very differen…

Yeah, for example embassy-rs is an RTOS that uses rust async on tiny microcontrollers. You can hook task execution up to a main loop and interrupts pretty easily. (And RTIC is another, more radically simple version which also uses async but just runs everything in interrupt handlers and uses the interrupt priority and nesting capability of most micros to do the scheduling)

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#9

Post by tuyiown »

maxloh wrote: post #8

In what extent is this compatible with Linux? Could I swap Ubuntu's or Android's kernel with this, while keeping those OSes bootable?

While it's very legitimate question, the answer is between the lines in the README, and it mostly means that there is a user space binary compatibility for everything that is implemented.

It might seem obscure, but syscalls to get access to kernel requires a tight integration on compilation and linking. So this is their approach and this is where the compatibility really means something : since you can cross compile on another machine, they don't need the full toolchain right away. Just compile your code on a linux machine, and run it there. You're at the mercy of all missing kernel API implementations, but it looks like a very good strategy if you aim is to code a kernel, as you only have to focus on actual syscalls implementation without getting distracted by toolchain.

Post reply on HN