POSSE

KL-OS: Page Table

2025-12-30

Day 9 was about memory management and virtual addressing.

The structure of the virtual address is defined by the RISC-V paging mechanism called Sv32. It uses a two level page table where the 32 bit virtual address is divided into a first-level page table index, a second level and a page offset. The tables are named VPN[1] and VPN[0] respectively.

First the macros for the construction of the page table are defined. Then the function to map pages map_page is made which is utilized in process creation. For that we also add an element called page_table on the struct of process. And to make everything work we define the starting address of the kernel space __kernel__base in the linker script just after boot.

To utilize the above setup of page tables and switch them, we specify the first-level page table in satp (Supervisor Address Translation and Protection) register.

I still need to understand more about this. I am not satisfied with the explanation from the resource.

KL-OS: Process

2025-12-29

Day 8 was about Process. Though, modern operating systems use the concept of threads to provide execution context. We treat processes like individual threads being run for our implementation.

First we define a structure for PCB (Process Control Block). We first define PROC_UNUSED and 0 and PROC_RUNNABLE as 1. Then we create a structure for a unit process with the following slots:

  • Process ID as an Integer.
  • State (PROC_UNUSED or PROC_RUNNABLE) as an Integer as defined before.
  • Stack Pointer as a vaddr_t (Virtual Address Type).
  • Kernel Stack as a list of unsigned 8bit Integers.

The Kernel Stack is essential for saving the registers while context switching.

Then, we defined the switch_context function that does the context switching. It takes the previous and next stack pointer as arguments and then switches them during execution. It saves the callee-saved registers into the stack, switches the stack pointer then restores the callee-saved registers from the stack. The execution context is saved as a temporary local variable on the stack.

Then, we work on process creation. The process creation function create_process takes in the entry point of the process as a parameter and then returns the process struct.

The delay function is also created to act as a sleep style function which just does nop (Nothing) for 30000000 clock pulses.

Then a scheduler is made to make the context switching more autonomous. A scheduler is basically a Kernel program which decides the next process.

Then, in the exception handler, we make it so that each process has it's own independent kernel stack. While switching, the contents of sscratch are switched too to resume the execution of process from where it was interrupted as if nothing had happened.

KL-OS: Memory Allocation

2025-12-28

Day 7 was about Memory Allocation. First the memory regions were defined in the linker script so that it can determine the position to avoid overlapping the memory to kernel's static data.

The size of the memory space was 64 * 1024 * 1024 bytes or 64MB and it is aligned to a 4KB boundary.

Then a function alloc_pages was implemented which allocated n pages of memory and returned it's starting address.

KL-OS: Exceptions

2025-12-27

Day 6 was about Exceptions and handling those Exceptions in the kernel.

In RISC-V the CPU first checks medeleg register to determine which operation mode should handle the exception. In our case U-mode/S-mode is already handled by OpenSBI. Then, the CPU saves states into various CSRs. stvec register is set to pc then the exception is handled using the handler. Then sret is called to resume execution from the point where exception occurred.

The handle_trap function reads why the exception occurred and triggers the kernel panic. Which was implemented yesterday.

KL-OS: PANIC

2025-12-26

Perfect topic for today because early morning I was shown why It was a stupid decision to do something, then at afternoon I got into a bike accident. Though it was minor with no injuries to both parties except some scratches on the bikes. It could have caused huge consequences. Then I did another mistake and then another.

PANIC!

It is day 5. Implementing panic was very easy, it is implemented as a macro because if we defined it as a function it would have printed the __LINE__ and __FILE__ where PANIC is defined and not where it is called. And to halt the kernel it uses a while true loop which goes on infinitely.

KL-OS: C Standard Library

2025-12-25

To make a useful kernel we require it to perform tasks like setting a memory chunk to zero, or copying the memory from a source address to destination address. It may have to understand what a boolean is or what NULL is. So, for that we require the "C Standard Library" and hence we need to implement it (or the functions it contains as abstractions to commonly used functions).

For this, in day 4 I utilized clang's internal C library as well as resorted to writing the functions all by myself.

KL-OS: Printing

2025-12-24

As the days progress the journey is getting more fun and interesting. It was the part where actual text was going to be printed. It was a kernel hello-world.

Day 3 focused on printing characters on the console by talking to SBI finally implementing putchar and eventually printf.

KL-OS: Boot

2025-12-23

The actual development of OS started with making the build script run.sh in bash to setup and launch a qemu RISC-V virtual machine with OpenSBI as bios for QEMU.

Then a linker script kernel.ld was made and a basic kernel process kernel.c was written. Finally, the build script was updated to include compiler and execution commands and flags to properly boot the kernel.

Day 2 focused on writing a basic starting process of a kernel and running it in a virtual machine.

KL-OS: Setting Up

2025-12-22

I have set up the environment required to run RISC-V 64 toolchain using QEMU.

Installed a debian RISC-V 64 iso and set it up to my liking with autologin and proper terminal emulation and sudo. I then installed gcc, gdb and neovim for writing and compiling programs.

Details of what happened on Day 1 is tracked using git with codeberg as a remote.

I have decided to use Operating System in 1000 Lines as the learning material because it was featured as a beginner level learning material in github:riscv/learn.

KL-OS: Checkpoint

2025-12-21

I want to learn systems programming and I thought why not go with the open source one which is currency in development. So, I chose the RISC-V architecture. That way if I decide to keep pursuing it, I can grow along with the ISA slowly catching up to it.

I want to keep a streak by posting here every day about what I learn. Let's hope it goes well.

Rusting

2025-08-28

Trying to replace as many apps I use with the apps written in rust to see how much is possible.

Continuous: Oxidation by flux was very helpful.