top | item 46012804

(no title)

hexagonal-sun | 3 months ago

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!

discuss

order

Rochus|3 months 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|3 months 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.

hexagonal-sun|3 months 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.

andrewl-hn|3 months ago

> no networking support

Would something like Smoltcp be of help here? 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|3 months 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.

phkahler|3 months 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.

bfrog|3 months 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.

nickpsecurity|3 months ago

MIT licensed code is a gift. A gift indeed doesn't require the recipient to give back anything related to the gift.

A "gift" requiring GPL-like conditions isn't really a gift in the common sense. It's more like a contractual agreement with something provided and specific, non-negotiable obligations. They're giving while also asserting control over others' lives, hoping for a specific outcome. That's not just a gift.

People doing MIT license are often generous enough where the code is a gift to everyone. They don't try to control their lives or societal outcomes with extra obligations. They're just giving. So, I'm grateful to them for both OSS and business adaptations of their gifts.

surajrmal|3 months ago

Do you think soup kitchens and food banks should only serve food to those who volunteer? MIT is a perfectly fine FOSS license.

cryptonector|3 months 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?

0x457|3 months ago

You just described android.

sheepscreek|3 months 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|3 months ago

BUt it's not "safe" because it's mixed with assembly

F3nd0|3 months 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|3 months 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?

Blikkentrekker|3 months ago

Copyleft doesn't work well with Rust's ecosystem of many small crates and heavy reliance on libraries alongside static linking.

If one library be GPLv2 and the other GPLv3 they couldn't be used together in one project. LGPL solves nothing because it's all statically linked anyway. And yes, one could licence under both under the user's choice but then GPLv4 comes out and the process repeats itself, and yes one could use GPLv2+ but people aren't exactly willing to licence under a licence that doesn't yet exist and put blind faith into whoever writes it.

Using anything but a permissive licence is a good way to ensure no one will lose your library and someone will just re-implement it under a permissive licence.

C is a completely different landscape. Libraries are larger and the wheel is re-invented more often and most of all dynamic linking is used a lot so the LGPL solves a lot.

tingletech|3 months ago

What is a "pushover" license?

IshKebab|3 months 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|3 months ago

Are the collaborations possible/foreseeable?

kennykartman|3 months ago

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

Onavo|3 months ago

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