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/b4c5ebea3ea8fa28243310854d...
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