Do I really need to add mount2 and umount3 syscalls for some crazy experiment

[Anadon <joshua.r.marshall.1991@gmail.com>]

I never post, be gentle.

I am looking into implementing a distributed RAFT filesystem for
reasons.  Before this, I want what is in effect a simple pass-through
filesystem.  Something which just takes in calls to open, read, close,
etc and forwards them to a specified mounted* filesystem.  Hopefully
through FUSE before jumping straight into kernel development.

Doing this and having files appear in two places by calling `mount()`
then calling the (potentially) userland functions to the mapped file
by changing the file path is a way to technically accomplish
something.  This has the effect of the files being accessible in two
locations.  The problems start where the underlying filesystem won't
notify my passthrough layer if there are changes made.  Since my end
goal is to have a robust consensus filesystem, having all the files
able to silently be modified in such an easy and user accessible way
is a problem.  What would be better is to have some struct with all
relevant function pointers and data accessible.  That sounds like
adding syscalls `int mount2(const char* device, ..., struct
return_fs_interface)` and `int umuont3(struct return_fs_interface)`.
Adding two new syscalls which look almost nothing like other syscalls
all in the name to break "everything is a file" in favor of
"everything is an API" is a lot.  It sounds like a fight and work I
would like to avoid.

I have looked at `fsopen(...)` as an alternative, but it still does
not meet my use case.  Another way would be to compile in every
filesystem driver but this just seems downright mad.  Is there a good
option I have overlooked?  Am I even asking in the right place?