Hi Cedrik,
Questions:
Seems a VFS plug-in is initialized first, before libc has had a chance to be initialized ?
While digging in the code, here is what I can gather: in the previous incarnation of the code, where FUSE is an FS server, the server would call Libc::Component::construct() early, which would initialize the libc/kernel: kernel = *unmanaged_singletonLibc::Kernel(..) and then subsequent calls to libc would work. But now, the VFS plug-in (and its libc-using code) is called first.
Is that the right explanation for my problem?
that's spot-on! The libc dependency of the fuse plugin makes the VFS implicitly dependent from the libc, which is unfortunate. We have a hen-and-egg problem.
So based on that 'evidence' alone, it would seem the event chronology is somewhat like this:
- test-harness is loaded by LD
- LD looks for its plugins, loads them, and executes them first (even
if they require libc)
- test-harness / struct Main is called, initializing libc etc
Maybe my FUSE plug-in should detect when libc is not yet initialized, reject all calls to its hooks done at that early time, and only honor them later on ?
That is an interesting idea but it violates the execution model of the libc. The VFS is part of the so-called libc kernel, which works like a state machine. Calls from the libc into the VFS are nonblocking. In contrast, the libc's interface is operated at the so-called application context that supports the notion of blocking I/O. Both execution contexts should never be mixed.
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.
Cheers Norman