34 lines
1.8 KiB
Markdown
34 lines
1.8 KiB
Markdown
# State Of Development
|
|
|
|
This file will serve as a living journal of what I'm working on with regards
|
|
to the project, so I can step away from it and come back to it without having
|
|
to figure out what I was doing from commit messages alone.
|
|
|
|
## 2026-10-08: TSS Descriptor Weirdness
|
|
|
|
Loading the TSS selector into the Task Register was causing endless general
|
|
protection faults, which seemed... odd. Turns out, I was performing some bad
|
|
encoding when generating the TSS descriptor in the GDT, as well as loading
|
|
the bytes in the wrong order. Fixing the descriptor generation code and
|
|
swapping the bytes was enough to fix the GPFs. Now, the kernel makes it to
|
|
usermode, before triple faulting due to page faults. This is probably because
|
|
I put the stack in a bogus, unmapped address.
|
|
|
|
The next issue to work on will be paging and memory allocation. I need to
|
|
allocate memory to load and start the initial process, and to do that, I
|
|
need to finalize how I want process page mappings to be stored. It has to
|
|
align with Gila's capability model. After that, I can write some basic
|
|
syscalls, and compile a very minimal binary to test running processes.
|
|
|
|
## 2026-10-11: Capability Data Structures
|
|
|
|
Starting to design the shape of capability structures. Using a doubly linked
|
|
list allows easy tracking of derived capabilities, but presents ownership
|
|
issues. I can't think of anything smarter than using raw addresses to denote
|
|
where capabilities are, so those are used as our references. We use null
|
|
checking and convert these pointers into `Option<&mut Capability>` whenever
|
|
possible to uphold safety.
|
|
|
|
The capability's fields allow a hierarchical structure for components and
|
|
capabilities, and in the future, user processes can create capabilities to
|
|
resources that aren't managed by the kernel. |