But also big props to Andreas for speaking so candidly about the back story of Serenity. I feel like there are certain things we don't talk about in tech and that can change.
I love the idea that programming, esp side projects, can be a therapeutic thing.
I'm definitely a fan of talking more about things that we've been hiding from each other.
On that topic, one of the most common questions I get personally is "which drugs did you use in the past?" and I recently made a video[1] answering that question. It was a difficult thing to get through, but the overwhelmingly supportive response has been amazing.
For anyone who's struggling and is afraid to open up about it, know that there's a community of millions around the world who will welcome you with open arms.
Now more technical questions ... for my own sake of understanding and learning.
What would you say that were most important aspects of re-implementing (subset of?) C++ runtime that must be appropriate for in-kernel usage?
Where would I look in the source code to learn about SerenityOS paging algorithms, and virtual memory management in general?
Something that I messed up originally and we're now correcting incrementally is the handling of allocation failures. There are many places in a kernel where errors don't have a natural propagation path (IRQ handling for example), so operations that may fail (like allocation) must be avoided.
In general, heavy use of C++ features like templates and RAII has been very helpful for making kernel development productive.
> Where would I look in the source code to learn about SerenityOS paging algorithms, and virtual memory management in general?
You'll find the kernel memory management code in https://github.com/SerenityOS/serenity/tree/master/Kernel/Me...
Quick breakdown:
- Every Process has an AddressSpace.
- An AddressSpace has a number of Region objects, each with a virtual base address, size, permission bits, etc.
- Every Region has an underlying VMObject.
- VMObject is virtual and can be AnonymousVMObject (MAP_ANONYMOUS) or InodeVMObject (MAP_FILE).
- Cross-process memory sharing occurs when two or more Regions in separate AddressSpaces use the same underlying VMObject.
- MemoryManager handles physical page allocation, fault handling, page tables, etc.
> Something that I messed up originally and we're now correcting incrementally is the handling of allocation failures.
What in particular? Can you use exceptions reliably in the kernel land? I presume not unless you pre-allocate some hard-to-exhaust space for them.
Have you maybe thought of using LSBs to encode an allocation failure within the pointer itself? It's an entertaining idea I had for some time now. In 64-bit byte-addressable architectures one can take advantage of suitable alignments and have 3 least significant bits used to encode 8 different states. In a similar vein one could also take advantage of MSBs given the virtual address memory space limit of nowadays CPUs.
I haven't thought about encoding allocation failure as a low pointer value. I suppose you could, but it'd only work for pointers with sufficient alignment. Character/byte pointers often start at unaligned offsets when not coming directly from an allocator. Either way, I'm not sure compressing this information would solve any real problem we're having.
[1] https://github.com/SerenityOS/serenity/blob/master/AK/Error....
[2] https://github.com/SerenityOS/serenity/blob/master/AK/Try.h
> Character/byte pointers often start at unaligned offsets
Yes, but the address of that pointer is still 8 bytes long and idea of using 3 LSB of that address to encode the state is still applicable, isn't it?
> How's that possible? Isn't that an UB?
"Unaligned" was not the best word to use. What I really meant was byte-aligned:
char* s = strdup("Hello world!");
char* p = &s[1];
Yeah, I figured just few moments after I replied what you actually meant. That's why I edited the post above.
Well, to make it more robust one would have to wrap it in it's own pointer type but I think it's doable. I don't know whether or not it is a wise choice to make it a dependency in the OS though :)
Really glad you guys got together for this.
It was a great episode to make I'm always looking for devs with interesting backstories to share so if have any ideas shoot me a message.