From 20bff5af7ee352181eac535522ba4d68f998de90 Mon Sep 17 00:00:00 2001 From: Erin Abicht Date: Wed, 19 Apr 2023 13:25:58 -0400 Subject: [PATCH] More filesystem ideas --- src/development/design/filesystem.md | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/src/development/design/filesystem.md b/src/development/design/filesystem.md index ab3129e..0c289a1 100644 --- a/src/development/design/filesystem.md +++ b/src/development/design/filesystem.md @@ -17,14 +17,21 @@ Therefore, the "filesystem" code will just be a library that's simple a low-leve ## Filesystem Layout + +| Name | Size | Header | +|------|------|--------| +| Boot Sector | `128` | `None` | +| Kernel Sector | `1024` | `None` | +| Config Sector | `u64` | `PartitionHeader` | +| User Sector(s) | `u64` | `PartitionHeader` | + ### Partition A virtual section of the disk. It's identified simply by numerical order. ```rust -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 +const LABEL_SIZE: u16; // Number of characters that can be used in the partition label -let NUM_CHUNLKS: u64; // Number of chunks in a specific partition +let NUM_CHUNKS: u64; // Number of chunks in a specific partition struct PartitionHeader { boot: bool, // Boot flag label: [char; LABEL_SIZE], // Human-readable label. Not UTF-8 though :/ @@ -63,8 +70,8 @@ Compression of the data should also be possible, due to `bincode` supporting [fl 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). +On boot, we start executing code from the **Boot Sector**. This contains the assembly instructions, which then jump to the `kernel` code in the **Kernel Sector**. +The `kernel` then reads in bytes from the first partition *(as the sectors are fixed-size, we know when this starts)* into memory, serializing it into a `PartitionHeader` struct via [bincode](https://lib.rs/crates/bincode). 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.