7 ms·

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 th

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 https://github.com/hexagonal-sun/moss Comments & contributions welcome!

bramadityaw 10mo ago
shouldn't this be a ShowHN?
Rochus 10mo ago
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.
- kaoD 10mo ago
  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.
  - rcxdude 10mo ago
    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)
    - Rochus 10mo ago
      Interesting references, thanks. Moss seems to be doing the same thing as Embassy.
    - boguscoder 10mo ago
      Sorry for nit but embassy is not a RTOS (or any OS), its a framework
      - rcxdude 10mo ago
        The difference becomes a bit murky at this level. For example embassy comes with a lot more things I would consider OS-related than FreeRTOS does.
  - Rochus 10mo ago
    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/ https://os.phil-opp.com/async-await/
  - vlovich123 10mo ago
    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.
- hexagonal-sun 10mo ago
  This has been a real help! The ability to easily verify the behavior of certain pieces of code (especially mem management code) must have saved me hours of debugging. Regarding the async code, sibling posts have addressed this. However, if you want to get a taste of how this is implemented in Moss look at src/sched/waker.rs, src/sched/mod.rs, src/sched/uspc_ret.rs. These files cover the majority of the executor implementation.
IshKebab 10mo ago
Impressive work! Do you have any goals, other than learning and having fun? Also how does it's design compare with Redox and Asterinas?
- cies 10mo ago
  Are the collaborations possible/foreseeable?
F3nd0 10mo ago
Congratulations on the progress. If I may ask, I'm curious what considerations have motivated your choice of licence (especially since pushover licences seem extremely popular with all kinds of different Rust projects, as opposed to copyleft).
- dymk 10mo ago
  I’ve pretty much only seen MIT and to a lesser extent GPL on most open source projects. Would you expect a different license?
- tingletech 10mo ago
  What is a "pushover" license?
  - WD-42 10mo ago
    It’s a play on “permissive” license.
  - nmz 10mo ago
    A derogatory term for copyfree licenses
  - SAI_Peregrinus 10mo ago
    Permissive license + complaining when companies don't contribute back from their forks.
    - cryptonector 10mo ago
      I've worked on plenty of BSD and MIT licensed code. I've never complained about lack of contribution. You're projecting. Please stop.
      - SAI_Peregrinus 10mo ago
        I'm not the person who used the term "pushover license". I just explained why some people use the term.
andrewl-hn 10mo ago
> no networking support Would something like Smoltcp be of help here? https://github.com/smoltcp-rs/smoltcp https://github.com/smoltcp-rs/smoltcp Great project either way! How do you decide which sys calls to work on? Is is based on what the user space binaries demand?
- hexagonal-sun 10mo ago
  Yip, I panic whenever I encounter a syscall that I can't handle and that prompts me to implement it. Yeah, I was thinking of integrating that at some point. They've done a really nice job of keeping it no_std-friendly.
  - whitequark_ 10mo ago
    Original author of smoltcp here! I couldn't have imagined how much of a cornerstone of the Rust ecosystem it would become. Very excited to see it get used like this, and yeah, #![no_std] use cases were the original and primary motivation to build the stack in the first place.
phkahler 10mo ago
Love the MIT license. If this were further along we could use this as the foundation of our business without having to "give back" device drivers and other things.
- cryptonector 10mo ago
  I take this as an oblique critique of TFA's choice of license. What's it to you? Why must we all use the GPL always in order to satisfy busybodies?
  - phkahler 10mo ago
    >> I take this as an oblique critique of TFA's choice of license. What's it to you? Why must we all use the GPL always in order to satisfy busybodies? Thank you for reading it correctly. I originally had a </sarcasm> to make sure nobody thought I liked the license choice. What's it to me? Well someone posted it to HN here so we could comment on it, so I did. I think the MIT license has its place, but IMHO it does not belong on an OS like that. Reason is indicated in my original comment.
    - cryptonector 10mo ago
      Glad the author disagrees with you. So do I.
- bfrog 10mo ago
  This should be the sort of red flag to take note of. There’s an LLVM fork for every esoteric architecture now and this sort of thinking will lead to never being able to run your own software on your own hardware again. A reversion to the dark ages of computing.
  - 533474 10mo ago
    Great, an MIT license to accelerate planned obsolescence and hardware junk. Truly a brilliant move
Onavo 10mo ago
How does android compatibility look? Can this be compiled to WebAssembly and run in browser?
sheepscreek 10mo ago
Very impressive and I like how accessible the codebase is. Plus safe Rust makes it very hard to shoot yourself on the foot, which is good for outside contributions. Great work! After you got the busybox shell running, how long did it take to add vim support? What challenges did you face? Did you cross-compile it?
- fortran77 10mo ago
  BUt it's not "safe" because it's mixed with assembly
  - scottlamb 10mo ago
    There are no programs written in 100% safe Rust—the std library is written with unsafe as needed. But typically the majority of lines in the program—sometimes even all outside std or some well-audited foundational creates—are safe. Those lines can not directly cause any unsoundness, which has tremendous value.
  - loeg 10mo ago
    This has been discussed ad nauseam and this adds nothing new. There's value in the memory safety for the majority of the code even if there are some escape valves ("unsafe" keyword, assembly).
kennykartman 10mo ago
Ah, nice. I wish this was licensed GPL instead of MIT. I'll avoid contribution, sorry!

bramadityaw 10mo ago

shouldn't this be a ShowHN?

Rochus 10mo ago

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.

kaoD 10mo ago
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.
- rcxdude 10mo ago
  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)
  - Rochus 10mo ago
    Interesting references, thanks. Moss seems to be doing the same thing as Embassy.
  - boguscoder 10mo ago
    Sorry for nit but embassy is not a RTOS (or any OS), its a framework
    - rcxdude 10mo ago
      The difference becomes a bit murky at this level. For example embassy comes with a lot more things I would consider OS-related than FreeRTOS does.
- Rochus 10mo ago
  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/ https://os.phil-opp.com/async-await/
- vlovich123 10mo ago
  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.
hexagonal-sun 10mo ago
This has been a real help! The ability to easily verify the behavior of certain pieces of code (especially mem management code) must have saved me hours of debugging. Regarding the async code, sibling posts have addressed this. However, if you want to get a taste of how this is implemented in Moss look at src/sched/waker.rs, src/sched/mod.rs, src/sched/uspc_ret.rs. These files cover the majority of the executor implementation.

IshKebab 10mo ago

Impressive work! Do you have any goals, other than learning and having fun? Also how does it's design compare with Redox and Asterinas?

cies 10mo ago
Are the collaborations possible/foreseeable?

F3nd0 10mo ago

Congratulations on the progress. If I may ask, I'm curious what considerations have motivated your choice of licence (especially since pushover licences seem extremely popular with all kinds of different Rust projects, as opposed to copyleft).

dymk 10mo ago
I’ve pretty much only seen MIT and to a lesser extent GPL on most open source projects. Would you expect a different license?
tingletech 10mo ago
What is a "pushover" license?
- WD-42 10mo ago
  It’s a play on “permissive” license.
- nmz 10mo ago
  A derogatory term for copyfree licenses
- SAI_Peregrinus 10mo ago
  Permissive license + complaining when companies don't contribute back from their forks.
  - cryptonector 10mo ago
    I've worked on plenty of BSD and MIT licensed code. I've never complained about lack of contribution. You're projecting. Please stop.
    - SAI_Peregrinus 10mo ago
      I'm not the person who used the term "pushover license". I just explained why some people use the term.

andrewl-hn 10mo ago

> no networking support Would something like Smoltcp be of help here? https://github.com/smoltcp-rs/smoltcp https://github.com/smoltcp-rs/smoltcp Great project either way! How do you decide which sys calls to work on? Is is based on what the user space binaries demand?

hexagonal-sun 10mo ago
Yip, I panic whenever I encounter a syscall that I can't handle and that prompts me to implement it. Yeah, I was thinking of integrating that at some point. They've done a really nice job of keeping it no_std-friendly.
- whitequark_ 10mo ago
  Original author of smoltcp here! I couldn't have imagined how much of a cornerstone of the Rust ecosystem it would become. Very excited to see it get used like this, and yeah, #![no_std] use cases were the original and primary motivation to build the stack in the first place.

phkahler 10mo ago

Love the MIT license. If this were further along we could use this as the foundation of our business without having to "give back" device drivers and other things.

cryptonector 10mo ago
I take this as an oblique critique of TFA's choice of license. What's it to you? Why must we all use the GPL always in order to satisfy busybodies?
- phkahler 10mo ago
  >> I take this as an oblique critique of TFA's choice of license. What's it to you? Why must we all use the GPL always in order to satisfy busybodies? Thank you for reading it correctly. I originally had a </sarcasm> to make sure nobody thought I liked the license choice. What's it to me? Well someone posted it to HN here so we could comment on it, so I did. I think the MIT license has its place, but IMHO it does not belong on an OS like that. Reason is indicated in my original comment.
  - cryptonector 10mo ago
    Glad the author disagrees with you. So do I.
bfrog 10mo ago
This should be the sort of red flag to take note of. There’s an LLVM fork for every esoteric architecture now and this sort of thinking will lead to never being able to run your own software on your own hardware again. A reversion to the dark ages of computing.
- 533474 10mo ago
  Great, an MIT license to accelerate planned obsolescence and hardware junk. Truly a brilliant move

Onavo 10mo ago

How does android compatibility look? Can this be compiled to WebAssembly and run in browser?

sheepscreek 10mo ago

Very impressive and I like how accessible the codebase is. Plus safe Rust makes it very hard to shoot yourself on the foot, which is good for outside contributions. Great work! After you got the busybox shell running, how long did it take to add vim support? What challenges did you face? Did you cross-compile it?

fortran77 10mo ago
BUt it's not "safe" because it's mixed with assembly
- scottlamb 10mo ago
  There are no programs written in 100% safe Rust—the std library is written with unsafe as needed. But typically the majority of lines in the program—sometimes even all outside std or some well-audited foundational creates—are safe. Those lines can not directly cause any unsoundness, which has tremendous value.
- loeg 10mo ago
  This has been discussed ad nauseam and this adds nothing new. There's value in the memory safety for the majority of the code even if there are some escape valves ("unsafe" keyword, assembly).

kennykartman 10mo ago

Ah, nice. I wish this was licensed GPL instead of MIT. I'll avoid contribution, sorry!