Abstracting out the file system code

[JustinCappos]

For some aspects of 3i and just modularity in general, it would be nice to have the file system parts of lind abstracted into a library. This way someone wanting to build an in-memory file system, something like the current file backed fs, or future file systems (like a network file system or one that reads straight to the underlying disk) would be able to reuse most of the code.

I think this needs to be discussed in detail before work happens, but I'd love to have this be abstracted out in a clean way.

[rennergade]

Definitely agree. I think this actually shouldn't be too hard.

I think the first thing that needs to happen to make it more apples to apples is getting rid of the FILEOBJECTTABLE (or changing how its used) in the current file backed FS. It would make more sense and be more interchangable if the inode struct just pointed to either the fileobject or the in-memory file struct. Though one problem I believe is that Rust will close the file if it goes out of scope, and if we keep an inode open from the inodetable it would cause deadlock. So for the file-backed FS we still need to keep a reference to the fileobject somewhere persistent.

After that I think its just a matter of:

• making different option defined versions of interface::file.rs and filesystem.rs
• some defines/refactoring around logging for the file backed log in fs_calls
• some minor refactoring of mmap and shared memory