I’ve pushed a basic remote macOS filesystem project to GitHub. Its got all the bits and pieces necessary to work but I haven’t audited all parts of it for correctness. I’ll do that as I start implementing each area. What’s complete is all the project infrastructure to do filesystem and kernel development. I can’t stress enough the importance of taking care of your development environment to get the code, compile, deploy/test, debug cycle working as fast as possible. I can go from a fresh checkout to compiled, deployed, unit tested (yes you can unit test in the kernel), and remote filesystem mounted in under a minute. There’s a lot going on to make the above happen as you will see.
What’s In The Box
To get a working macOS filesystem you need three things: filesystem, kernel extension and NetFS plugin. Now the last one isn’t technically necessary but if you’re being a good steward of the platform you should include it.
This is what lives in the /Library/Filesystems folder. You can see the shipped filesystems by looking at /System/Library/Filesystems. For the most part there isn’t much code here. What you’ll find is the very important Info.plist describing the filesystem and
associated utilities such as mount, fsck, newfs, etc. Since Lustre is a remote filesystem we just have mount.
The core of how a filesystem is implemented in it’s kernel extension. This lives in the /Library/Extensions folder and is structured like any other kernel extension. There’s one important difference from most other kernel extensions though. In the Info.plist there’s this:
[code]OSBundleAllowUserLoad [/code] If you plan to have a filesystem which may be mounted by normal (non-Admin) users, they need to be able to load the associated kernel extension. This key allows that to happen.