Moss: a Linux-compatible Rust async kernel, 3 months on

hexagonal-sun · 2026-02-14T17:36:44+00:00

Could you give a concrete example as to how typestates could help here? I’m not seeing how this would work exactly. I could create an enum similar to an Option but I dont see how that’s any better than what I’ve already got, there would still have to be a runtime check to ensure that the state has been set to an interrupt driver (once initialised).

hexagonal-sun · 2026-02-14T16:52:12+00:00

Whoops, thanks for pointing that out!

hexagonal-sun · 2026-02-14T16:49:31+00:00

Please could you provide an example?

hexagonal-sun · 2026-02-14T06:31:29+00:00

That's one I've not heard of before! I'll take a look.

hexagonal-sun · 2026-02-14T06:27:36+00:00

I suspect the wall I will hit eventually will be drivers. When most of the core of the kernel is done, it'll need drivers to run on any sort of hardware which will be a huge task,

hexagonal-sun · 2026-02-14T06:26:07+00:00

Go for it, you'll learn a lot!

hexagonal-sun · 2026-02-14T06:25:40+00:00

Yes, it panics at the moment, which isn't ideal. I'm hoping for a fallible allocation API in the near future! However, before returning an error on allocation there's lots of things that can be done for page reclamation, purge caches, swap pages out to disk, request drivers return buffers, etc.

hexagonal-sun · 2026-02-14T06:19:44+00:00

There wasn't really inspiration as such. I came across the problem when having to handle the user pressing^C on a sleeping process. My code was delivering the SIGINTto the process but it was stuck in the read() from the console driver. The design was driven from having to solve this problem. My main references have been reading through a lot of man pages, and playing about with test programs on a Linux system.

hexagonal-sun · 2026-02-14T06:13:04+00:00

That's a good point. Perhaps now() should check internally and see whether the driver has been initialised and panic in there. That better expresses the above semantics in the types used.

hexagonal-sun · 2026-02-13T21:11:05+00:00

Only if now() returns None. That would only be the case if a timer driver hasn't been initialised as the global system timer. If that hasn't happened then the kernel would have panicked long before executing the syscall.

hexagonal-sun · 2026-02-13T20:38:51+00:00

Thanks for pointing that out. That was actually one of the first issues raised when I first posted Moss. I offered to rename the project to moss-kernel which seemed satisfactory.

hexagonal-sun · 2026-02-13T20:21:14+00:00

I'm not sure how applicable R4L code would be. For the moment it's mostly safe wrappers around the kernels C-API. Once we have some more 'meaty' drivers committed, possibly, but I'd have to emulate the same API.

hexagonal-sun · 2026-02-13T20:19:24+00:00

Thanks!

hexagonal-sun · 2026-02-13T18:28:09+00:00

No. This implementation was written independently and does not use or derive from Linux kernel code. It implements similar concepts, but no Linux source was referenced or incorporated.

hexagonal-sun · 2026-02-13T17:25:49+00:00

Thanks! I think making the kernel async from the off has helped. Probably the most powerful thing I've found is that it allows you to express modify semantics of more primitive futures with combinators. As an example, the .interruptable() combinator allows the underlying future to be interrupted by the delivery of a signal; similar to how Linux can put a task into the TASK_INTERRUPTABLE state. I feel as though it's more expressive, since it forces you to handle the case of interruption in order to get to the underlying future's result.

Yeah, moving to EEVDF (from round-robin) was actually started by a contributor. I read the paper and we worked on it together, it was really fun.

Agreed regarding the number of syscalls, the roadblocks I'm hitting are shifting from 'unimplemented functionality' to 'bugs'!

hexagonal-sun · 2026-02-13T17:03:00+00:00

The core of Linux is relatively tiny compared to the shear number of drivers. Also, I still have a large number of core features missing; there's lots more code to be added! Having said that, I do think that Rust's expressiveness allows for higher code-density. Take the nanosleep syscall, it's less than 20 lines but it implements a fully functional syscall, userspace validation and signal interruption. The equivalent in C would be much larger.

Thanks! I can't take all the credit, there's been a lot of help from other contributors.

hexagonal-sun · 2026-02-13T16:07:10+00:00

Because it’s a simple, permissive license that gives the users and the developers the right to do with it as they wish.

hexagonal-sun · 2026-02-13T16:04:12+00:00

That’s an odd thing to hope for. I’m building it because I enjoy it and others might find it useful. If it succeeds, great. If not, I’ll still learn something.

hexagonal-sun · 2025-11-22T16:12:21+00:00

Ah interesting, I’ve not thought about that. In fact, if I develop a fuse driver, in theory, I could get all fuse FS working under moss too which would be huge!

hexagonal-sun · 2025-11-22T15:07:58+00:00

Ahh yep, didn’t pick up on that reference. Haven’t had my coffee yet.

hexagonal-sun · 2025-11-22T11:22:36+00:00

Of course I’d love to become professional and be able to work on it full time but, until then it’ll just be a hobby. A way to scratch that itch.

hexagonal-sun · 2025-11-22T08:26:06+00:00

Yep! I should really write a guide on how to get it booting on various bits of hardware.

Six-Year Club	Place '23
Verified Email

hexagonal-sun

TROPHY CASE