You are browsing as a guest. Sign up (or log in) to start making projects!

6h 43m 53s logged

how much fun we shall have

so you may be wondering… where the hell was I for the past 6 hours. I was putting together the foundation for my VFS, with a ton of struggles.

what

so in my last devlog, I came up with all the storage structures and measurements for how the filesystem works on Astatine. But I was yet to implement a single function. So i started basic, and that still somehow screwed up too bad

1. Splitting paths by forward slashes

this seems really simple, but I messed it up somewhat bad. Since I don’t have a C library or strtok, I implemented my own string splitting thing using dynamic arrays (that I implemented) and a buffer. The unfortunate thing is that my dynamic arrays return a pointer to the value you save to it. Since I’m saving a pointer to a string, which in turn is a pointer of characters, I have to cast everything to a char**, while the default return types are all void*, so when I freed the strings, I forgot to dereference them (and the compiler didn’t complain), resulting in a kernel panic screen.

2. macro hell (in expansion of hashmap)

next, I need to implement a VFS global cache. when you access a path, it’s better to save the data in ram so that the next time you visit that path we aren’t traversing the directory again. unfortunately, i’m dumb and don’t know how to implement a hashmap, so I found this interesting tutorial from a decade ago and used that.

I also thought, at this point in time, that it would make sense to add thread safety to the vfs code so that it doesn’t completely crash due to race conditions, and I introduced macros for these. However, I realised that non-atomic writes are still not thread safe, and had to dig in with compiler builtins (since I’m using freestanding code, I can’t use <stdatomic.h>).

While putting together these macros with atomic, I had some weird behaviour where I kept hanging and hanging and hanging, and turns out it was because my macros were made improperly, and the formatting of the code meant that the while statements I was using to loop over code didn’t actually cover the entire loop body, resulting in a permanent hang.

3. malloc vs calloc

this is my fault, I forgot to use calloc to get zeroed memory, since my code seems to have failed to initialise all the required sections, it resulted in a page fault.

4. well this is embarassing

about at least 25 times, i kept a debug statement that dereferenced a null pointer, causing a crash. this was so sad because it taught me to remember: i’m stupid.

so does it work?

yea. thank my 2012 macbook air’s horribly patched version of qemu for the slowdown in the next clip. (i also included the crash so you can see the cool ntos-like crash screen)

0
15

Comments 0

No comments yet. Be the first!