# Development

If you're wanting to help develop **Mercury**, you've come to the right place!
Again, right now we're a heavy work-in-progress. But eventually this will be useful!

## Contributor Agreements
By submitting resources to this project (code, art, writing, etc.), you must agree to the following terms:
1. Resources will be licensed under the [CNPLv7+](https://thufie.lain.haus/NPL.html) license
2. You *must* follow the [Code of Conduct](code-of-conduct.md)
3. You should follow the [Design Goals](/development/design/index.md) and [Best Practices](#best-practices) when possible

Otherwise, feel free to start contributing!

## Best Practices
These are various "best practices" for code written for the **Mercury** project.
They should be followed when reasonable, to the best of your ability/understanding.
Feel free to [contact](https://mercury.the-system.eu.org/contribute/) a maintainer with questions!

- No compromises will be made for compatibility. If there is a better, if unusual, way to do things, it should be done that way.
- Everything must be fully accessible. Everything else can be sacrificed for this.
- `unsafe` code should be avoided when possible.
- Everything should be documented as it is written.
- Nesting should be avoided as much as possible.
- If something can be excluded from the main `kernel`, it should be. It's a `microkernel`!
- Features should be *opt-in* rather than *opt-out*.

## Source Code
All of the source code for **Mercury** is on a self-hosted [Gitea](https://git.lavender.software/mercury), courtesy of [Lavender Software](https://lavender.software).
Sign up there, and contact one of the maintainers to get access to the repositories.

The source for this site, and our [website](https://mercury.the-system.eu.org) is available there as well.

### Design
All `crates`/`libraries` are in a `no-std` environment. This means we only have access to the [libcore](https://doc.rust-lang.org/core/) functionality.
However, we will be using the `alloc` crate to access the heap, and`collections` to have access to data structures like `Vec`.

We should, however, have basic support for [async](https://ferrous-systems.com/blog/stable-async-on-embedded/) and [threading]() in `core::`.

## Learning
Before jumping in, I highly recommend learning some stuff abotu **Rust** and embedded development with it.
A thorough series of steps might be:
1. Read through the [Rust Book](https://doc.rust-lang.org/book/)
2. Work through the [Interactive Rust Book](https://rust-book.cs.brown.edu/)
3. Complete the [rustlings](https://github.com/rust-lang/rustlings) exercises
4. Take a quick look through the [Embedded Rust Book](https://docs.rust-embedded.org/book/intro/index.html)
5. Read the [RISC-V Guide](https://github.com/mikeroyal/RISC-V-Guide)/[RISC-V Bytes](https://danielmangum.com/categories/risc-v-bytes/) to learn more about the **RISC-V** architecture
6. Read the OSDev Wiki entries on [Microkernels](https://wiki.osdev.org/Microkernel) and [Message Passing](https://wiki.osdev.org/Message_Passing)
7. Read the [Async Book](https://rust-lang.github.io/async-book/01_getting_started/01_chapter.html)

Additionally you might want to learn about **Vulkan** if you're going to be hacking on the [GUI](/development/design/gui.md):
1. Go through the [Vulkan Tutorial (Rust)](https://kylemayes.github.io/vulkanalia/introduction.html) to learn some of the basics
2. Read through the [Vulkano](https://vulkano.rs/about.html) docs. *(**Vulkano** is a safe wrapper around the **Vulkan API**. It's likely what we will be using)*