54 lines
3.6 KiB
Markdown
54 lines
3.6 KiB
Markdown
# 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/embedded-concurrency-patterns/) 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)
|
|
8. [This](https://sled.rs/perf.html) has some good information about performance
|
|
|
|
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)*
|