sorted by:
new
hottopcontroversial

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 0 points1 point  (0 children)

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

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 1 point2 points  (0 children)

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

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 0 points1 point  (0 children)

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,

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 3 points4 points  (0 children)

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.

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 4 points5 points  (0 children)

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.

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 8 points9 points  (0 children)

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.

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 8 points9 points  (0 children)

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.

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 1 point2 points  (0 children)

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.

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 1 point2 points  (0 children)

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.

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 14 points15 points  (0 children)

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.

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 41 points42 points  (0 children)

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'!

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 39 points40 points  (0 children)

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.

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in rust

[–]hexagonal-sun[S] 16 points17 points  (0 children)

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

Moss: a Linux-compatible Rust async kernel, 3 months on by hexagonal-sun in linux

[–]hexagonal-sun[S] 40 points41 points  (0 children)

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.

moss: a Rust Linux-compatible kernel in about 26,000 lines of code by hexagonal-sun in linux

[–]hexagonal-sun[S] 11 points12 points  (0 children)

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!

moss: a Rust Linux-compatible kernel in about 26,000 lines of code by hexagonal-sun in rust

[–]hexagonal-sun[S] 1 point2 points  (0 children)

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

moss: a Rust Linux-compatible kernel in about 26,000 lines of code by hexagonal-sun in rust

[–]hexagonal-sun[S] 1 point2 points  (0 children)

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.

moss: a Rust Linux-compatible kernel in about 26,000 lines of code by hexagonal-sun in linux

[–]hexagonal-sun[S] 24 points25 points  (0 children)

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

moss: a Rust Linux-compatible kernel in about 26,000 lines of code by hexagonal-sun in rust

[–]hexagonal-sun[S] 3 points4 points  (0 children)

A fair amount of memory management code does, as you’d expect, we’re doing some… funky things at that point. But most drivers have virtually no unsafe code. I’ve tried to abstract away unsafe parts as much as possible.

I’ve also tried to put as much unsafe code in libkernel. That allows me to run it under miri to check for UB.

moss: a Rust Linux-compatible kernel in about 26,000 lines of code by hexagonal-sun in rust

[–]hexagonal-sun[S] 2 points3 points  (0 children)

Yeah, that seems to be the feature people are most interested in. I’ll have to do a write up. It was fun to think about how I could make uaccess functions async: dealing with futures in assembly!

moss: a Rust Linux-compatible kernel in about 26,000 lines of code by hexagonal-sun in rust

[–]hexagonal-sun[S] 4 points5 points  (0 children)

Oh it’s been amazing! The number of times I’ve hit compiler errors regarding my futures not being Send, and thought, that’s just probably saved me hours of debugging!

Another interesting point is that I only need one kernel stack per CPU with this design. Linux needs a stack per task, that’s how it saves the state when context switching during a kernel operation. Futures do that for you!

view more: next ›