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

ttcoder at netcourrier.com ttcoder at netcourrier.com
Thu Nov 25 12:32:41 CET 2021

Hey Genode team, fellow Genodians,

I'm trying to modify FUSE-server to become a VFS plug-in (see genode-world#193) but it seems "with_libc()" no longer works, when in a plug-in attached to the test-libc_vfs test harness:

[init -> test-libc_vfs] ---->open_Dir
[init -> test-libc_vfs] Error: Uncaught exception of type 'Libc::Kernel::Kernel_called_prior_initialization'
[init -> test-libc_vfs] Warning: abort called - thread: ep


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?

Alternative explanation:
maybe the libc framework from the _host_ component is not shared with its child VFS plug-in at all ?


I then removed calls to libc, and added some tracing to the now
free-flowing code, to get some sense of chronology, determine who is
called when.

The result was interesting: it seems when a VFS plug-in is instantiated,
its hooks are called before anything else is called (I'm not the one calling
them, as my code is still at an early "skeleton" stage yet, I make no
call to opendir() etc, so someone else is doing that), including even
before the host "Main" :

[init -> test-libc_vfs] ---->open_Dir
[init -> test-libc_vfs] ---->num_dirent
[init -> test-libc_vfs] ---->directory
[init -> test-libc_vfs] ---->directory
[init -> acpi_drv] SMBIOS table (entry point: 0x165700 structures:
[init -> platform_drv] ECAM/MMCONF range
00000000:00000000.0-000000ff:0000001f.7 - addr
[init -> test-libc_vfs] test-libc-vfs: ctor of struct Main : reading
config ROM
[init -> test-libc_vfs] test-libc-vfs: entering with_libc()
[init -> test-libc_vfs] test-libc-vfs: calling test() from libc context
[init -> test-libc_vfs] ---->leaf_path
[init -> test-libc_vfs] Error: Uncaught exception of type 'Test_failed'

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 ?


More information about the users mailing list