gila/docs/STATE_OF_DEVELOPMENT.md
August a384ebec4f
All checks were successful
Continuous Integration / Check (push) Successful in 1m2s
Continuous Integration / Clippy (push) Successful in 1m5s
Capability structure start
2026-10-11 21:55:45 -04:00

1.8 KiB

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.