VFS plug-in that requires early libc initialization (for FUSE)

[ttcoder at netcourrier.com]

> I'm afraid that this leaves only one viable solution: To stub the I/O
> interplay of fuse with the libc and map those interactions directly to
> the raw VFS, not going through the libc. This is tedious but the only
> clean way I can see. It would essentially remove the dependency of the
> fuse VFS plugin from the libc's I/O operations, alleviating the cyclic
> dependency.
> 
> Note that freestanding libc functionality like string operations are ok
> to use. E.g., the ttf VFS plugin depends on the libc in such a "weak"
> way because the stb library used for the glyph rendering happens to call
> few libc utilities. But I/O is a no go.

Organizing my thoughts and looking for inspiration:

1) Stubbed Libc:

I see there is a "mini libc" which supports the run/demo scenario.

And there is somewhat larger one for lwext4 here, inside include/ and libc.cc:

  https://github.com/genodelabs/genode-world/tree/master/src/lib/lwext4

(probably I should look at this (and fatfs, and...) more in depth, see how they deal with access to the "Block device" sans calling read()/seek() but using the Genode API instead.)

So I could do something similar, except I'd stub/shim read(), write() and ioctl()
(which NTFS/Fuse make heavy use of) instead of just malloc() and strcpy().

Beyond my NTFS/BFS/XFS use cases there would likely be more use cases,
so it might make sense for me to refactor whatever I come up with into
an e.g. world/src/lib/generic-libc/ library or some such.

Then, said static (?) library would be common to (and linked to) components that need it,
including the various FUSE file systems.


2) Late loading:

Alternatively, I have to wonder whether some runtime loading (instead of launchtime loading)
of the VFS plug-in would make sense. Generally speaking, Genode supports dlopen()-style loading of .so libraries,
so I suppose if the VFS server gets fully loaded, and then later its "config" ROM gets amended
with an extra plug-in, then the plug-in would be initialized with a full LibC context.

Genode/Sculpt has gotten various "dynamic scenarios" over the years, I wonder if that one is implemented ?
It might be a "nice-to-have", beyond the immediate problem discussed here,
since it's nice to be able to try out new FS plug-ins without rebooting Genode.


Anyway, will dig into all that in the coming weeks...

Cedric