Q: How should we debug while we develop?
A: Two ways we recommend: 
    1. Use the utilities in utils.h to check what functions you encounter failures in
    2. Set up kgdb. Details are in the README
    3. You can print stack traces (e.g. https://elixir.bootlin.com/linux/v6.15/source/lib/dump_stack.c#L126)

Q: How should we parallelize our work?
A: There are details in the "Work Division Suggestions" section of the README

Q: What's the difference between creat and create?
creat() is a system call, create() is a FS callback.
The path goes:
(syscall) creat("/mnt/c"): https://elixir.bootlin.com/linux/v6.15/source/fs/open.c#L1516
(syscall) do_sys_open(..., "/mnt/c", O_CREAT | O_WRONLY | O_TRUNC); (only O_CREAT matters for us)
(VFS) do_filp_open() -> path_openat() -> open_last_lookups() -> lookup_open(): https://elixir.bootlin.com/linux/v6.15/source/fs/namei.c#L3701
(VFS) invokes dir_inode->i_op->create()

i_op is an inode_operations struct, and create() is the function your FS implements that VFS invokes


Q: Why does the code fail to compile?
A: It's likely an issue with the Makefile. Make sure to edit the Makefile to compile against 6.15 modules. By default it routes to $LINUX_PATH, which is a path in my (Sid's) local machine

Q: Why might there be frequent crashes?
A: For all the same reasons as prior kernel modules, + because you'll be sharing state with VFS and revoking it, and there are many subtle ways that can mess up.

Hints about 1.3
The general flow of the mount path is:
    read SB from disk
    read other relevant metadata from disk
    read root inode information

Almost every helper function/data structure in the super.c and inode.c code map to one of those 3 functionalities, so that can help you build your mental model.