VFS plug-in that requires early libc initialization (for FUSE)
norman.feske at genode-labs.com
Tue Nov 30 16:17:34 CET 2021
> 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
> kernel = *unmanaged_singleton<Libc::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
> 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
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.
Dr.-Ing. Norman Feske
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
More information about the users