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

11–20 of 163 posts

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

#11

Post by Rochus »

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…

Ok, I see. I spent a lot of time with .Net VMs, where you cannot simply separate await from the heavy machinery that runs it. I now understand that in a kernel context, you don't need a complex runtime like Tokio. But you still need a way to wake the executor up when hardware does something (like a disk interrupt); but this indeed is not a runtime dependency.

EDIT: just found this source which explains in detail how it works: https://os.phil-opp.com/async-await/

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

#12

Post by Rochus »

rcxdude wrote: post #7
kaoD wrote: post #5

Earlier quoted context omitted.

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)

Interesting references, thanks. Moss seems to be doing the same thing as Embassy.

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

#13

Post by vlovich123 »

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…

There’s got to be some complexity within the executor implementation though I imagine as I believe you have to suspend and resume execution of the calling thread which can be non-trivial.

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

#15

Post by kaoD »

vlovich123 wrote: post #13
kaoD wrote: post #5

Earlier quoted context omitted.

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…

There’s got to be some complexity within the executor implementation though I imagine as I believe you have to suspend and resume execution of the calling thread which can be non-trivial.

You can implement an executor with threading to achieve parallelism, but it's not a fundamental characteristic of Future executors.

To reiterate: an executor is just something that runs Futures to completion, and Futures are just things that you can poll for a value.

See sibling comments for additional details.

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

#18

Post by vlovich123 »

kaoD wrote: post #15
vlovich123 wrote: post #13

Earlier quoted context omitted.

There’s got to be some complexity within the executor implementation though I imagine as I believe you have to suspend and resume execution of the calling thread which can be non-trivial.

You can implement an executor with threading to achieve parallelism, but it's not a fundamental characteristic of Future executors. To reiterate: an executor is just something that runs Futures to completion, and Futures are just things that you can poll for a value. See sibling comments for additional details.

I’m aware; you’re not adding new information. I think you’re handwaving the difficulty of implementing work stealing in the kernel (interrupts and whatnot) + the mechanics of suspending/resuming the calling thread which isn’t as simple within the kernel as it is in userspace. eg you have to save all the register state at a minimum but it has to be integrated into the scheduler because the suspension has to pick a next task to execute and resume the register state for. On top of that you’ve got the added difficulty of doing this with work stealing (if you want good performance) and coordinating other CPUs/migrating threads between CPUs. Now you can use non interruptible sections but you really want to minimize those if you care about performance if I recall correctly.

Anyway - as I said. Implementing even a basic executor within the kernel (at least for something more involved than a single CPU machine) is more involved, especially if you care about getting good performance (and threading 100% comes up here as an OS concept so claiming it doesn’t belies a certain amount of unawareness of how kernels work internally and how they handle syscalls).

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

#19

Post by kaoD »

vlovich123 wrote: post #18
kaoD wrote: post #15

Earlier quoted context omitted.

You can implement an executor with threading to achieve parallelism, but it's not a fundamental characteristic of Future executors. To reiterate: an executor is just something that runs Futures to completion, and Futures are just things that you can poll for a value. See sibling comments for additional details.

I’m aware; you’re not adding new information. I think you’re handwaving the difficulty of implementing work stealing in the kernel (interrupts and whatnot) + the mechanics of suspending/resuming the calling thread which isn’t as simple within the kernel as it is in userspace. eg you have to save all the register state at a minimum but it has to be integrated into the scheduler because the suspension has to pick a nex…

No. I am adding new information but I think you are stuck on your initial idea.

There's no work stealing. Async-await is cooperative multitasking. There is no suspending or resuming a calling thread. There is no saving register state. There is not even a thread.

I will re-reiterate: async-await is just a state machine and Futures are just async values you can poll.

I'm sure moss has an actual preemptive scheduler for processes, but it's completely unrelated to its internal usage of async-await.

See embassy in sibling comments.

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

#20

Post by juliangmp »

marty-oehme wrote: post #10

Very cool project! I do have to admit - looking far, far into the future - I am a bit scared of a Linux ABI-compatible kernel with an MIT license.

I agree, I know a lot of people aren't huge fans of it but in the long run Linux being GPL2 was a huge factor in its success.
Post reply on HN