hexagonal-sun

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.

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.

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.

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!

Hello!

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.

You can find it on GitHub: https://github.com/hexagonal-sun/trale And on crates.io: https://crates.io/crates/trale

Would love to hear your thoughts or feedback!

Announcing trale v0.2.0!

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.

Check it out:

GitHub: https://github.com/hexagonal-sun/trale Crates.io: https://crates.io/crates/trale

Feedback appreciated!

Hello everyone!

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.

Thanks!

As a learning exercise on unpicking how Rust's async really works, I created trale. It's a tiny, fully working execution envinroment for async rust code on Linux. It currently stands at < 1000 lines and is fully featured. My hope is that this code will help lift some of the 'magic' around how async Rust works for other people interested in this field!

This is a project to connect two Linux machine's network stacks via the amateur radio bands. It uses Linux's TAP interface to read & write packets at layer 2 to/from the kernel. QPSK modulation is used at the RF layer.

For now experimentation has mainly been done in a Ramsey box. The next step is to add a callsign field to the QPSK frames so the data can be legally TX'd.

Agreed, syntax highlighting would be great. I was thinking about something akin to fish's syntax highlighting and completion with the REPL.

I'll take a look at tree-sitter. If I get syntax highlighting for free then I'll take that!

Thanks! It's still a work in progress but should hopefully help people to get to grips with C.

Huh, I didn't know about that tool. Looking through the docs this looks impressive, especially since it can do C++ too.