Remix.run Logo
hexagonal-sun 6 days 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!

F3nd0 3 hours ago | parent | next [-]

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 33 minutes ago | parent | next [-]

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 27 minutes ago | parent | prev [-]

What is a "pushover" license?

andrewl-hn 3 hours ago | parent | prev | next [-]

> 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 2 hours ago | parent [-]

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 hours ago | parent | prev | next [-]

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 hours ago | parent | next [-]

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 2 hours ago | parent | next [-]

Great, an MIT license to accelerate planned obsolescence and hardware junk. Truly a brilliant move

surajrmal an hour ago | parent [-]

Linux magically solves this problem how? GPL isn't magic. It doesn't compel contributing upstream. And half of modern driver stacks live in userspace anyways.

mikelpr 37 minutes ago | parent [-]

> And half of modern driver stacks live in userspace anyways ??? I haven't touched hardware whose driver lives in userspace since 2017 and it was a DMX512 controller of a shitty brand

surajrmal 9 minutes ago | parent [-]

They seem to be primarily targeting arm. A lot of drivers live in userspace for arm socs, especially on the higher end.

imiric 2 hours ago | parent | prev [-]

Seriously.

To the author: kudos for the interesting project, but please strongly consider a copyleft license moving forward.

surajrmal an hour ago | parent | prev | next [-]

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

imiric 35 minutes ago | parent [-]

No, but if someone takes the free food and builds a business by selling it to others, without giving anything back to the original places, it harms everyone other than the person doing that.

F/LOSS is not a charity or a gift, so your analogy is not appropriate. It is a social movement and philosophy with the goal of sharing knowledge and building software for the benefit of everyone. It invites collaboration, and fosters a community of like-minded people. Trust is an implicit requirement for this to succeed, and individuals and corporations who abuse it by taking the work of others and not giving anything back are harmful to these goals. Copyleft licenses exist precisely to prevent this from happening.

MIT is a fine license for many projects, but not for an operating system kernel.

surajrmal 3 minutes ago | parent [-]

This feels eerily close to having someone try to convince me to be join their religion. You don't need to force your opinions into others. Let them choose. If folks agree then the license will hold them back in terms of building a community. There are plenty of great open source kernels that don't use GPL, including freebsd. I think most embedded os kernels are not gpl (zephyr, freertos, etc). I would argue that Linux does well in spite of its license not because of it.

nickpsecurity 2 hours ago | parent | prev [-]

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.

vacuity 2 hours ago | parent | next [-]

While the FSF's vision for the GPL is clear, the GPL itself is not so powerful that it is more than a "gift" that has some terms if you want to do certain things you are not obligated to do. It is like a grant that enforces some reasonable conditions so the money isn't just misappropriated. I wouldn't give that to a friend for their birthday, but I think it's reasonable that powerful organizations should not be free to do whatever they want. Not that the GPL is perfect for that use, but it's good.

naasking 2 hours ago | parent | prev | next [-]

MIT is throwing a free party where food and drinks are paid for, and copyleft is where food is paid for but you BYOB. Both are fine, so what's the problem?

imiric 2 hours ago | parent | prev | next [-]

A gift where the recipient can remove the freedoms that they've been enjoying themselves is a bad deal for ensuring those freedoms are available to everyone. A permissive license is a terrible idea for a F/LOSS kernel.

This is the paradox of tolerance, essentially.

Also, seeing F/LOSS as a "gift" is an awful way of looking at it.

pessimizer 2 hours ago | parent | prev [-]

> It's more like a contractual agreement with something provided and specific, non-negotiable obligations.

The obligation is not to the author of the code, it is to the public. MIT-style licenses are gifts to people and companies who produce code and software, copyleft licenses are gifts to the public.

I don't give a shit about the happiness of programmers any more than the happiness of garbage collectors, sorry. I don't care more that you have access to the library you want to use at your job writing software for phones than I care that somebody has access to the code on their own phone. You're free to care about what you want, but the pretense at moral superiority is incoherent.

It is non-negotiable. GPL is basically proprietary software. It's owned by the public, and all of the work that you do using it belongs to the public. If you steal it, you should be sued into the ground.

pstoll an hour ago | parent [-]

I get what your saying but I think it’s not the best way to describe it - “GPL is property”? Hardly - it’s a societal common good that can be used by anyone interested in helping that common good.

Are parks “proprietary”? I can’t run my car dealership from one, so it’s …proprietary? No. So using the terminology of “proprietary” doesn’t do justice to what it actually is.

wredcoll 22 minutes ago | parent [-]

The phrasing is a little awkward but I like the sentiment: gpl software is owned by the public/humanity/the commons/etc in the same way something like the grand canyon should be.

Rochus 6 hours ago | parent | prev | next [-]

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 6 hours ago | parent | next [-]

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 6 hours ago | parent | next [-]

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)

boguscoder 14 minutes ago | parent | next [-]

Sorry for nit but embassy is not a RTOS (or any OS), its a framework

Rochus 5 hours ago | parent | prev [-]

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

Rochus 5 hours ago | parent | prev | next [-]

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/

vlovich123 5 hours ago | parent | prev [-]

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.

kaoD 5 hours ago | parent [-]

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.

vlovich123 5 hours ago | parent [-]

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

kaoD 5 hours ago | parent [-]

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.

hexagonal-sun 4 hours ago | parent | prev [-]

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 6 hours ago | parent | prev | next [-]

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

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

bramadityaw 6 hours ago | parent | prev [-]

shouldn't this be a ShowHN?