Indeed! There are a few parts where I resorted to AI (mainly for the unit tests in libkernel), but I made sure to read through the generated code and that the tests were sane.
Eventually, It'd be amazing to use Moss as my daily driver OS. That means targeting the specific hardware that I have, but in doing so, I hope to build up enough of the abstractions to allow easier porting of hardware.
A more concrete mid-term goal is for it to be 'self-hosting'. By that I mean you could edit the code, download dependencies and compile the kernel from within Moss.
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.
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.
I've just released trale v0.3.0 — my attempt at building a small, simple, but fully-featured async runtime for Rust.
Trale is Linux-only by design to keep abstraction levels low. It uses io_uring for I/O, and provides futures for both sockets and file operations.
The big feature in this release is multishot I/O, implemented via async streams. Right now, only TcpListener supports it — letting you accept multiple incoming connections with a single I/O submission to the kernel.
I'm excited to announce the release of trale v0.2.0! This release brings several important updates that will improve the overall performance and usability of the project.
Key Features:
- Reactor port: Successful port of the reactor from using epoll-based IO to *io\_uring*. This change should result in improved performance and scalability for IO operations.
- New futures module: The switch to `io_uring` allows file-system based futures to be written. To that end, a new `fs` module that provides asynchronous methods for file system operations has been added. This includes async file reading, writing, opening, and creating directories.
- New webserver example: This release includes a new web server example demonstrating the new `fs` futures module! While it's a basic HTTP server implementation, it demonstrates some impressive performance benchmarks. On localhost, it can achieve up to 25,000 requests per second (or 399,385 KB/sec) on a single thread, though keep in mind it's unoptimized for production use.
I'm excited to announce the first release of trale, my minimalistic asynchronous executor crate! This project is designed to provide a simple yet functional educational resource for those studying Rust's async ecosystem. Since my initial post, there have been significant improvements and simplifications in the code, especially in the reactor and the addition of several new future types.
The goal of this crate is not only to provide a working executor, but also to serve as a learning resource for understanding how async systems work under the hood—particularly for those interested in exploring Rust’s async capabilities and its interaction with low-level Linux system interfaces.
Future work planned is a port to use Linux's io_uring API.