Contribution

[SwoleDuck]

Hello, i am interested in contributing to this project.

I cloned the repo ( latest commit = a150e89 ) and had some tests/runs with it.

I found some minor bugs, will open some issues for them as i think this is not the right place to state them.

Finally, if you dont have any problems of me contributing then it would be nice to give me some guideline in the next steps( ex "create folder" etc ) so that we wont work in the same component.
I didnt find any email and the discord link was not working so I hope a notifications pops when i start the discussion.

[xing1357]

Yeah, I am open to new contributors for this project. You can either open some issues for the bugs, or state them here. Then, we can see where to go from there.

[SwoleDuck]

As far as bugs goes i only found about the sse and __stack_chk_fail_local, we could implement a function that enables sse as its a widely used instruction set. For the __stack_chk_fail_local problem, you could give me your os distro so that i install a vm and work on that.

Also, in the ext2.h file, the ext2_inode struct contains an array of uint32 direct_block_pointers[11], which means we have 11 blocks before we start using the indirect block pointers. But in the osdev wiki https://wiki.osdev.org/Ext2#Inode_Data_Structure the blocks are from 0 to 11, which means it must be an array of 12 entries.

Finally, i've been trying to understand the ext2 fs and your implementation and i was thinking if i could start creating a vfs ( especially the resolve path name component ) so that we can test with a more easy way the position of directories instead of using ext2_read_dir(inode_num);. If you agree i will send a better description of my thought process and start implementing it or i could work with something else if there is any need of help in some other part.

[xing1357]

So what are your thoughts on a vfs? I have been interested in such a thing but haven't really gotten started on it.

[SwoleDuck]

So the idea came from the function ext2_read_dir() in the ex2,c file. The first function calls with inode number 2 and works fine but the second prints just rubbish. I thought that if we implemented the vfs, it would be much easier if we just input something like resolve_path_get_inode(String*) and check the contents of the file.

Also, for the code to be more expandable, i though of implementing a filesystem struct which holds pointers (linked list) to all the filesystems who are mounted (each filesystem will have a unique identifier). For now its only the ext2 hd, but i think you would like to implement something like /proc, /dev, or even being able to mount a usb. Its still to early to be thinking about the above concepts but it would be nice if we worked with that mindset

The first version of the vfs will have a struct which points to a linked list with all the filesystem (currently only to ext2.c, we can create a struct in ext2.h which will hold information like the sb, bgdt and will have funtions like get_inode etc), The vfs will also have a resolve_path function which will check if we are going into a directory or not and maybe handle symlinks (i havent checked how they are implemented yet). In the long run this will return a linked list with the absolute path ( starting from the root all the way to the leaf). For now it will only return an inode so that we list the files in the directory. This function would also be used in the process of a open syscall, write, read etc.

The vfs will be initialized right after initializing ext2 and we will mount the root into it. It will definitely need a lot more things that what i just said. I haven't started working on it yet, just made some research. I can start coding tomorrow if i get the ok from you and you want to see my implementation.

[xing1357]

Sure, make a fork, and start some code. I have read thru some tutorials in the past week, like JamesM's kernel tutorial vfs, and have a good understanding. So yeah, theres the go ahead, and we'll see what modifications we can make.