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 _______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
