Making an RISC-V OS (Part 3): Managing free memory • Hacker News Board

Re: Making an RISC-V OS (Part 3): Managing free memory

#11

Post by ajxs » Wed, Apr 10, 2024, 12:04 PM UTC

lelanthran wrote: post #6

Wouldn't it be more accurate to call this "Making a RISC-V Bootloader"? As nice as this was to read (and I read all three parts), it's basically all the functionality of grub (or similar). For toy OSes on x86/x86_64 the best way to get started is to use grub to do all the setup and then launch the kernel.

I don't really understand what you mean. What is bootloader-like about this project? Any kernel, no matter what platform it targets, is going to look pretty similar to this project at this stage.

Re: Making an RISC-V OS (Part 3): Managing free memory

#12

Post by ajxs » Wed, Apr 10, 2024, 12:16 PM UTC

Very cool series! I've been working on the same kind of project, so I'm looking forward to the rest of the entries! I'd love to know more about why you opt for a higher-half kernel. Most hobby RISC-V kernels I've seen don't map kernel memory into a process' address space, and use a trampoline page to transition between kernelspace and userspace. Does this approach avoid the need to have a distinct address space for the kernel, and reload its 'satp' during traps? I found that one benefit of not mapping my kernel memory to the higher-half was that things that need physical addresses, like VirtIO or OpenSBI methods, were more straightforward to implement. Since my kernel heap was essentially identity mapped.

Also, cool static-site-generator! Your code syntax highlighting looks great too.

Re: Making an RISC-V OS (Part 3): Managing free memory

#13

Post by traxys » Wed, Apr 10, 2024, 1:58 PM UTC

ajxs wrote: post #12

Very cool series! I've been working on the same kind of project, so I'm looking forward to the rest of the entries! I'd love to know more about why you opt for a higher-half kernel. Most hobby RISC-V kernels I've seen don't map kernel memory into a process' address space, and use a trampoline page to transition between kernelspace and userspace. Does this approach avoid the need to have a distinct address space for t…

I have not really thought too far ahead, I know quite a bit about Linux internals, so when in doubt I tend to follow what was done there. I have not though very far in how to handle most of syscalls, traps, drivers, ...

Thank you for the static site generator! The code highlighting should be very similar to the tokyonight nvim colorscheme, as it uses mostly the same colors & tree-sitter queries as it!