Hello Genodians
I'm working on enabling vfs plugins that use libc, specifically a ported library. The library accesses a hardware device through a file in vfs, so there is no using a minimal libc implementation as it's the libc's vfs access that creates the chicken and egg problem preventing vfs plugins with libc.
The best solution I could think of this far is a special vfs server component that uses two vfs, one the hosts the libc using plugins and another that provides the vfs libc needs.
I've created a small code sample to demonstrate: https://github.com/throwException/genode/tree/libc_vfs
What do you think about this problem/solution?
Hi Stefan,
On 2/10/23 10:29, Stefan Thöni wrote:
I'm working on enabling vfs plugins that use libc, specifically a ported library. The library accesses a hardware device through a file in vfs, so there is no using a minimal libc implementation as it's the libc's vfs access that creates the chicken and egg problem preventing vfs plugins with libc.
...
What do you think about this problem/solution?
without having looked at the code, I got mixed feelings from your problem statement.
On the one hand, making VFS plugins depend on the (regular) libc is a direction I would stay away from. I worry that this direction creates problems, complexities, and wrong expectations that are far more difficult to handle than stubbing out or emulating a few POSIX calls from a ported 3rd-party library. The hosting of multiple VFS instances inside one component may be technically feasible but it is arguably not natural.
On the other hand, it is laudable that to got this to work.
BTW, the topic reminds me on Cedric's work on FUSE-based file systems discussed at [1].
[1] https://github.com/genodelabs/genode-world/issues/193
Cheers Norman
-
Norman Feske -
Stefan Thöni