search

sunriseos / SunriseOS

Horizon/NX kernel reimplementation
Apache License 2.0
231 stars 13 forks source link

Whats really the point of all this? #591

Closed xnuken closed 4 years ago

xnuken commented 4 years ago

As the title says what is the point of SunriseOS

roblabla commented 4 years ago

Let me preface this by saying that SunriseOS is not and will likely never be a user-facing project. No, you won't ever run Atmosphere with the SunriseOS kernel on it. No, you probably will never use it to run games.

SunriseOS started as a school project for me, @orycterope and @Thog. The original vision was to make an ABI-compatible kernel implementation in Rust. That goal is obviously lofty, and I never really expected us to reach it. But we wanted to see how close we could get, and learn as much as possible about kernel development and Horizon/NX in the process. A common question we get is "Why does SunriseOS target i386?" and the reason is quite simple: it was a requirement of the school :). We tried hard to design things in such a way that porting to ARM should remain possible.

As the project grew, we ended up with has broadly three subprojects all being encompassed under SunriseOS:

For the time being, I'm sort of treating SunriseOS like a playground in which I can implement cool ideas and toy with technologies I want to learn about. I'm currently working on implementing a network stack on top of SmolTCP (a TCP/UDP/IP stack) and virtio-net (a virtual network device for qemu). I'm also planning on implementing virtio-gpu support for hw-accelerated windows, and maybe rewriting the compositor to get proper window management. Those are all part of the "userspace" part of SunriseOS, which aren't really meant to ever become useful to anyone other than me.

Libuser is basically the new Megaton-Hammer. It takes all the lessons I learned while working on the former, and exposes the kernel and IPC API in the nicest possible way I could think of. I'm overall fairly proud of it, and think it would be a good fit for pure-rust homebrew on the Nintendo Switch. Ideally, I need to add ARM64 support and split it off in its own library. It'd also probably need a bit of splitting up (e.g. moving the future executor out of libuser, potentially integrating it into smol), but overall there shouldn't be too much work needed to put it into production use.

As for the kernel, the ABI it implements right now is fairly incomplete: We're missing synchronization primitives, multi-processing support, a proper scheduler, and many many other features. I'm interested in adding all of those, but it takes a lot of time, and I have a huge pile of other things I want to try out before. The first thing I want to implement in the kernel right now is DeviceAddressSpace syscalls, in order to have a proper, secure IOMMU.

I'm going to close this issue since it isn't really actionable, but feel free to reply here if you've got any further questions. Also, you can go on the Megaton-Hammer discord where most of the team hang arounds.