using a C library within a VFS plugin

[ttcoder at netcourrier.com]

> > So what is the proper way to do this?
> A VFS plugin may only use very limited LibC functionality. In many
> aspects this constellation could be compared to the execution of an
> application program inside the kernel on Linux. So it's tricky to get
> right and stable. I suggest to look for other options if pthreads
> and/or blocking file-system operations come into play.
> 
> Beside that you may look into a prior discussion on this list [1] and
> the FUSE genode-world issue [2] (esp. Norman's reply [3]) for
> inspiration.
> 
> [1] https://lists.genode.org/pipermail/users/2021-November/007828.html
> [2] https://github.com/genodelabs/genode-world/issues/193
> [3] https://github.com/genodelabs/genode-world/issues/193#issuecomment-985327
> 679

The wolftpm's page says their code is tuned for portability and has no external dependancy, so who knows, maybe could be feasible ? In case it is, thought I'd give additional inspiration about this:

In my specific case, I intended to make the ntfs-3g driver available in Genode ; in the end I realized it basically depends
on open()/read()/write()/close() and the like, so that was feasible.
What does it look like? Well it's not available from my repo yet, but cnuke was kind enough to make a backup copy of my code on github, look in particular for file "directfs_libc.cc" here:

  https://github.com/genodelabs/genode-world/commit/b4c5ebea3ea8fa28243310854d594c3afb99a38f#diff-8b00c8a3ce98aa620c2d30ec61ce550d9a661a5bb75b3b4389aee077e04c74b9

I patched an existing Genode-labs file, added a big "extern C...." block (sans aliasing the function names for now).
It's ugly as sin (I tend to go "field expedient" when in a major hurry), but might give an idea of how un-complicated the concept is, provided you have a back-end for your pseudo libc.

On a more general note...

Grep'ping through the genode and genode-world repos for re-implementations of strlen(), malloc(), or even open/read/close(), one finds quite a few hits (including the oldest one, from the original repo/demo folder! :-). Then there's my effort mentionned above. Then there will be (?) Stefan's new effort. That's a few instances of duplicated effort/wheel re-inventing.

So it might make sense to consolidate all of this a little bit in the future, i.e. Genode could provide not only their full-fledged LibC based on FreeBSD libc, but also a "micro-libc" for projects that are content with a small subset of libc features including a malloc()/free() pair based on a simple allocator, and so on. Such a 'mini-C' variant would probably require a bit more effort from the user (like "you need to call this initializer at such point from your code, you need to provide a back-end for read/write", etc), but they would be happy to at least have such a trade-off available, instead of facing a rewrite of their libC-using code to make it Genode-API-using code :-). Food for thought.

Cedric