Misc. fixes

src/README.md

@@ -7,6 +7,12 @@ It consists of docs for [Developers](/development/index.md), as well as [end-use
 
 If you would like to use the operating system, or help with development, this is where to get your information!
 
+## What is Mercury?
+**Mercury**, or the **Mercury Project**, refers to the collection of `libraries`, `crates`, and other code under this organization.
+"Organization" is a loose term, and really it's anyone who contributes and follows the [Code of Conduct](code-of-conduct.md).
+
+**Mercury OS** refers specifically to the full Operating System built off of the `ferrite` [kernel](/development/design/kernel.md) and all the other binaries.
+
 ## Status
 Right now, **Mercury** is mainly in the planning stage.
 We're still setting things up, learning, and planning out how we're going to do this.

src/SUMMARY.md

@@ -2,15 +2,18 @@
 
 [Introduction](README.md)
 
+# Developer Guide
 - [Development](development/README.md)
     - [Understanding the Design Goals](development/design/README.md)
         - [Actor System]()
-        - [Security Features]()
-        - [Microkernel]()
+        - [Security Features](development/design/security.md)
+        - [Microkernel](development/design/kernel.md)
         - [GUI]()
         - [Filesystem](development/design/filesystem.md)
     - [Configuring a Build Environment](development/environment.md)
     - [Development Workflow](development/workflow.md)
+
+# User Guide
 - [Using the OS](user/README.md)
     - [Running in a Virtual Machine]()
     - [Running on Baremetal]()
@@ -19,3 +22,7 @@
         - [Navigating the GUI]()
         - [Configuring the System]()
         - [Working with Actors]()
+
+-----------
+
+[Code of Conduct]()

src/code-of-conduct.md

@@ -0,0 +1 @@
+# Code of Conduct

src/development/README.md

@@ -6,7 +6,7 @@ Again, right now we're a heavy work-in-progress. But eventually this will be use
 ## 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](conduct.md)
+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!
@@ -21,14 +21,31 @@ Feel free to [contact](https://mercury.the-system.eu.org/contribute/) a maintain
 - `unsafe` code should be avoided when possible.
 - Everything should be documented as it is written.
 - Nesting should be avoided as much as possible.
-- `cargo fmt` must be used before each commit.
 - If something can be excluded from the main `kernel`, it should be. It's a `microkernel`!
-- While binary size should be kept down and optimized, it should not be done at the cost of performance.
 - Features should be *opt-in* rather than *opt-out*.
-- Releases should ideally contain no compiler or `clippy` warnings.
 
 ## 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/).
+
+## 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)
+
+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)*

src/development/design/README.md

@@ -19,6 +19,11 @@ Additionally, **Mercury** is designed for `ARM`/`RISC-V` architecture machines.
 This is not only because they are simpler, but also because I believe they are the future of computing.
 For the future, I do not see myself wanting or attempting to implement `x86` functionality.
 
+We may also use [Rhai](https://lib.rs/crates/rhai) for scripting, for easy user control & modification of the system.
+
+It will also use a global configuration - similar to **Guix** or **NixOS**. This allows it to be easily setup.
+It will likely use [RON](https://lib.rs/crates/ron) for configuration.
+
 Further design decisions are gone into detail in the next few chapters.
 
 ## Code Organization
@@ -34,6 +39,6 @@ Most of the code will be implemented as libraries, enabling for them to be used
 - [ferrite](https://git.lavender.software/mercury/ferrite-kernel) - The core microkernel code
 - [hermes]() - The package manager
 - [meteor]() - The [actors](/development/design/actor.md) library/implementation
-- [gravitas]() - The library for working with [storage](/development/filesystem.md)
+- [gravitas]() - The library for working with [storage](/development/design/filesystem.md)
 - [pulsar]() - Networking code
 - [photon]() - GUI library

src/development/design/filesystem.md

@@ -12,42 +12,49 @@ I don't want to provide a simple filesystem interface to programs like **UNIX**
 Instead, all data should be just stored in *actors*, then the actors will decide whether or not they should be saved.
 They can save at any time, save immediately, or just save on a *shutdown* signal.
 
-Therefore, the "filesystem" code will just be a library that's simple a low-level interface for actors to use.
+Therefore, the "filesystem" code will just be a library that's simple a low-level interface for the `kernel` to use.
+*Actors* will simply make requests to save.
 
 
 ## Filesystem Layout
 ### Partition
 A virtual section of the disk.
-- **BOOT Partition:** Fixed-size partition at the beginning of the disk, containing the kernel code, and info about the other partitions.
-- **DATA Partition:** Fixed-size partition containing misc. *Actor* data
-- **USER Partition:** Contains all data from the `User` [namespace](/development/design/actor.md#namespaces)
+It's identified simply by numerical order.
 ```rust
-enum PartitionLabel {
-    Boot,
-    Data,
-    User,
-}
+const BOOT_SIZE: u64; // How large the BOOT partition will be
+const LABEL_SIZE: u64; // Number of characters that can be used in the partition label
 
 struct PartitionHeader {
-    label: PartitionLabel,
+    boot: bool, // Boot flag
+    label: [char; LABEL_SIZE], // Human-readable label. Not UTF-8 though :/
     num_chunks: u64, // Chunks in this partition
 }
 ```
 
 ### Chunk
 Small pieces that each partition is split into.
-Contains fixed-length metadata (checksum, dates) at the beginning, and then arbitrary data afterwards.
-If the saved data exceeds past a single chunk, the metadata lists this.
+Contains fixed-length metadata (checksum, extension flag, uuid) at the beginning, and then arbitrary data afterwards.
+If the saved data exceeds past a single chunk, the `extends` flag is set.
+
+Additionally, it has a **UUID** generated via [lolid](https://lib.rs/crates/lolid) to enable identifying a specific chunk.
+
 ```rust
+const CHUNK_SIZE: u16; // Example static chunk size
+
 struct Chunk {
     checksum: u64,
     extends: bool,
-    data: [u8; 512],
+    encrypted: bool,
+    uuid: Uuid,
+    data: [u8; CHUNK_SIZE],
 }
 ```
 This struct is then encoded into bytes and written to the disk. Drivers for the disk are *to be implemented*.
 It *should* be possible to do autodetection, and maybe for *Actors* to specify which disk/partition they want to be saved to.
 
+Compression of the data should also be possible, due to `bincode` supporting [flate2](https://lib.rs/crates/flate2) compression.
+Similarely **AES** encryption can be used, and this allows for only specific chunks to be encrypted.[^encryption]
+
 ### Reading
 On boot, we start executing code from the beginning of the disk (the boot partition, although that's meaningless at this point).
 The `kernel` then reads in bytes from the first partition *(as the **BOOT** partition is fixed-size, we know when this starts)* into memory, serializing it into a `PartitionHeader` struct via [bincode](https://lib.rs/crates/bincode).
@@ -55,7 +62,7 @@ The `kernel` then reads in bytes from the first partition *(as the **BOOT** part
 From here, as we have a fixed `CHUNK_SIZE`, and know how many chunks are in our first partition, we can read from any chunk on any partition now.
 On startup, an *Actor* can request to read data from the disk. If it has the right [capabilities](/development/design/actor.md#ocap), we find the chunk it's looking for[^find_chunk], parse the data (using `bincode` again), and send it back.
 
-Also, we are able to verify data. Before passing off the data, we re-hash it using [ahash](https://lib.rs/crates/ahash) to see if it matches.
+Also, we are able to verify data. Before passing off the data, we re-hash it using [HighwayHash](https://lib.rs/crates/highway) to see if it matches.
 If it does, we simply pass it along like normal. If not, we refuse, and send an error [message](/development/design/actor.md#messages).
 
 ### Writing
@@ -70,6 +77,12 @@ Again, whether actors can:
 
 will be determined via [capabilities](/development/design/actor.md#ocap)
 
+### To-Do
+- Snapshots
+- Isolation
+
+[^encryption]: Specific details to be figured out later
+
 [^find_chunk]: Currently via magic. I have no idea how to do this other than a simple search. Maybe generate an index, or use a **UUID**?
 
 [^free_chunk]: Again, no idea how.

src/development/design/kernel.md

@@ -1 +1,25 @@
 # Microkernel
+The core `kernel` of **Mercury** will be highly limited, implementing only necessary portions.
+This allows other functionality to be simply run in userspace.
+
+Additionally, most code should be put into separate libraries then pulled into the `kernel` code.
+This will likely be done via `git submodules`.
+
+Initially, it will be built for `RISC-V`, then `ARM` *(focused on running in a [VM](/user/virtual-machine.md))*, then on a **Raspberry Pi**.
+Afterwards, we can put focus towards building out various features.
+
+Support for multiple targets will be done via `Cargo.toml` targets, cross-compilation, and [conditional compilation](https://doc.rust-lang.org/reference/conditional-compilation.html).
+
+## Boot Process
+*To be implemented*
+
+## Memory Management
+*To-Do*
+
+## Processes
+*To-Do*
+- [postcard](https://lib.rs/crates/postcard) for message passing
+
+## Error Handling
+All errors must be handled gracefully by the `kernel`. If possible, they should simply log an error.
+If not, they can display it to the user, preferably in a simple format, maybe using something like [const_panic](https://lib.rs/crates/const_panic) or [snafu](https://lib.rs/crates/snafuhttps://lib.rs/crates/snafu).

src/development/design/security.md

@@ -1 +1,14 @@
 # Security Features
+**Mercury** is designed with security in mind from the beginning.
+
+- First, we will be using [Orion](https://lib.rs/crates/orion) - a pure **Rust** crypto library.
+- There is built in support for checksums and **AES** encryption in the [filesystem](/development/design/filesystem.md).
+- **HMAC**[^hmac] will be used for message passing - which additionally allows for encrypted messages.
+- [nanorand](https://lib.rs/crates/nanorand) RNG
+- [HighwayHash](https://lib.rs/crates/highway) is used for checksums
+- [Argon2id](https://lib.rs/crates/argon2) is used for key-derivation
+
+## Isolation
+*To-Do*
+
+[^hmac]: https://cryptobook.nakov.com/mac-and-key-derivation