Compare commits
No commits in common. "4cce6065b0ef886679ab1b82df2b64504c1c4719" and "7c04c6f8ace938aaf48c921f28cb00327092477a" have entirely different histories.
4cce6065b0
...
7c04c6f8ac
|
@ -37,37 +37,10 @@ All of the code will take place in seperate repositories.
|
|||
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.
|
||||
Similarly drivers will be libraries in `git submodules`.
|
||||
|
||||
- [ferrite](https://git.lavender.software/mercury/ferrite-kernel) - The core microkernel code w/ bootloader
|
||||
- [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/design/filesystem.md)
|
||||
- [pulsar]() - Networking code
|
||||
- [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])
|
||||
```
|
||||
|
|
|
@ -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.
|
||||
|
||||
```rust
|
||||
const CHUNK_SIZE: u64; // Example static chunk size
|
||||
const CHUNK_SIZE: u16; // Example static chunk size
|
||||
|
||||
struct Chunk {
|
||||
checksum: u64,
|
||||
|
@ -81,32 +81,6 @@ will be determined via [capabilities](/development/design/actor.md#ocap)
|
|||
- Snapshots
|
||||
- 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
|
||||
|
||||
[^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**?
|
||||
|
|
Loading…
Reference in New Issue