Compare commits

..

3 Commits

Author SHA1 Message Date
~erin 4cce6065b0
Minor additions 2023-04-18 23:52:16 -04:00
~erin 064988574a
Basic executable format writeup 2023-04-18 16:17:27 -04:00
~erin 8fdbee17bc
Mermaid diagrams to explain stuff better 2023-04-18 16:16:47 -04:00
2 changed files with 55 additions and 2 deletions

View File

@ -37,10 +37,37 @@ All of the code will take place in seperate repositories.
Information on actually commiting, pulling, etc. is in the [Workflow](/development/workflow.md) chapter. Information on actually commiting, pulling, etc. is in the [Workflow](/development/workflow.md) chapter.
Most of the code will be implemented as libraries, enabling for them to be used across systems, and worked on separately. Most of the code will be implemented as libraries, enabling for them to be used across systems, and worked on separately.
Similarly drivers will be libraries in `git submodules`.
- [ferrite](https://git.lavender.software/mercury/ferrite-kernel) - The core microkernel code - [ferrite](https://git.lavender.software/mercury/ferrite-kernel) - The core microkernel code w/ bootloader
- [hermes]() - The package manager - [hermes]() - The package manager
- [meteor]() - The [actors](/development/design/actor.md) library/implementation - [meteor]() - The [actors](/development/design/actor.md) library/implementation
- [gravitas]() - The library for working with [storage](/development/design/filesystem.md) - [gravitas]() - The library for working with [storage](/development/design/filesystem.md)
- [pulsar]() - Networking code - [pulsar]() - Networking code
- [photon]() - GUI library - [photon]() - GUI library
## Overall Design
### Connections
```mermaid
erDiagram
BOOTLOADER ||--|| KERNEL: runs
KERNEL ||..o{ GRAVITAS: uses
KERNEL }|..o{ METEOR: uses
GRAVITAS }|..o{ HAL: uses
GRAVITAS ||--o{ DISK: IO
KERNEL ||--|{ MEMORY: maps
KERNEL ||--o{ EXE: runs
EXE }|..o{ METEOR: uses
EXE }|..o{ KERNEL: msg
```
### Startup Flow
```mermaid
flowchart TD
[[Bootloader]] --> kern(Kernel)
kern --> disk(Read Disk) -->
parse(Parse Configuration) --> run(Run Startup Programs)
parse -.-> sh([Interactive Shell])
kern --> mem(Map Memory) -.-> parse
run ==> actor([Create Actors])
```

View File

@ -39,7 +39,7 @@ 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. Additionally, it has a **UUID** generated via [lolid](https://lib.rs/crates/lolid) to enable identifying a specific chunk.
```rust ```rust
const CHUNK_SIZE: u16; // Example static chunk size const CHUNK_SIZE: u64; // Example static chunk size
struct Chunk { struct Chunk {
checksum: u64, checksum: u64,
@ -81,6 +81,32 @@ will be determined via [capabilities](/development/design/actor.md#ocap)
- Snapshots - Snapshots
- Isolation - Isolation
## Executable Format
Programs written in userspace will need to follow a specific format.
First, users will write a program in **Rust**, using the **Mercury** libraries, and with `no-std`.
They'll use [Actors](/development/design/actor.md) to communicate with the `kernel`.
Then, they'll compile it for the proper platform and get a pure binary.
This will be ran through an *executable packer* program, and the output of which can be downloaded by the package manager, put on disk, etc.
It'll then parsed in via `bincode`, then the core is ran by the `kernel` in userspace.
Additionally, the raw bytes will be compressed.
Then, whether reading from [chunks](#chunk) from memory or disk, we can know whether it will run on the current system, how long to read for, and when the compressed bytes start (due to the fixed length header).
It is then simple to decompress the raw bytes and run them from the `kernel`.
```rust
enum Architecture {
RiscV,
Arm,
}
struct PackedExecutable {
arch: Architecture,
size: u64,
compressed_bytes: [u8],
}
```
[^encryption]: Specific details to be figured out later [^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**? [^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**?