only a little unixy @tethys-official - Tumblr Blog

now it's up to thread-local (or core-local to be more specific) storage for the kernel. after this is context switching and loading the first user-mode program!

#osdev

currently quite far out to sea from rewrite no.4

#osdev

i should add the github repo to this blog's bio...

#osdev

yaaay i don't know why i didn't check to see if there were any no_std elf parsers in the first place! the only thing left for the kernel is... scheduling :(

#osdev

now we're up to writing structures + functions for process control. this might be difficult because the filesystem messaging architecture i've chosen for interprocess communication means process control is tightly coupled with the syscall interface

#osdev

okay actually we will be running the kickstart process in user mode because syscall/sysret makes nested interrupts so much easier and they're not possible to use from ring 0

#osdev

now we are mapping a general interrupt stack, a double fault stack, and a critical exception stack (non-maskable interrupt, machine check exception) for each processor. might add a page fault stack later.

#osdev

we have now set up per-processor gdt's rather than per-processor tss's in a shared gdt. now i can finally move on; this issue demotivated me enough that i stopped working for 3 weeks

#osdev

okay change of policy we love the x86_64 crate now

#osdev

i have decided to delay implementing the abi to instead just try loading a user program first in kernel mode and then using that to help debug the interface. this does mean the kernel will need an elf parser though.

#osdev

we now have the third draft of the abi specification (the first was part of a plan for writing something like this in c before i had any idea how to write a kernel, only how to structure the userspace)

#osdev

now time to set up structures for paging without the x86_64 crate. this one might be a little easier than if we were to use the crate, because it's so tightly integrated with the kernel's page frame allocator and caching/lazy allocation/copy-on-write/demand paging/whatever policies that the crate's interface HAS to be messy

#osdev

now we have a bootstrap gdt and the facilities to set up a real gdt of dynamic size without the x86_64 crate

#osdev

actually i'm not sure how much use the x86_64 crate is providing at this point. was great until i needed more flexibility, but now i guess it might be time to remove it

time for another complete rewrite -_-

#osdev

the x86_64 crate doesn't easily let you allocate a variable-sized gdt, so now i am writing completely new gdt structures and loading

#osdev

now we need to allocate a kernel stack (and also a double fault stack, for the processor to swap to if a "double fault" occurs (which is a cpu exception during the handler of another cpu exception), so that we know that we're working with an uncorrupted stack) for each processor

#osdev

once we have a page frame allocator bitmap, we loop through the memory regions that the bootloader gave us to mark all of the "usable" memory regions as free, and everything else (bootloader, kernel code, bios/uefi data, acpi reserved, etc.) as "used"

#osdev

Trending Blogs

Recently Viewed Blogs

only a little unixy