VFS plug-in that requires early libc initialization (for FUSE)

[Norman Feske]

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_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
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

-- 
Dr.-Ing. Norman Feske
Genode Labs

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