Re: [fuse-devel] An example fusemod, that could be integrated into FUSE's examples/ directory

[Fabrice B. <li...@gm...>]

Hello,

2013/8/6 Fabrice Bauzac <li...@gm...>:
> There is a warning though: like all .so fusemods, it suffer from a
> glibc bug described in:
> http://www.sourceware.org/ml/libc-help/2013-07/msg00015.html
> http://www.sourceware.org/ml/libc-help/2013-08/msg00005.html
> and as such, the compiled module will fail to register correctly into
> FUSE if FUSE has been compiled with -O2, until glibc is fixed.  As a
> workaround, you can compile FUSE with -O0 (./configure CFLAGS=-O0).
>
> Also, feel free to discuss this bug on the libc-help mailing list.

Concerning this issue, maybe an even better solution would be to
change the protocol used by FUSE to register fusemods.

At the moment, FUSE does the following:

fuse.c:
 fuse_current_so = so;
 so->handle = dlopen(soname, RTLD_NOW);
 fuse_current_so = NULL;

Upon dlopening, the .so's registered constructor function (created by
FUSE_REGISTER_MODULE()) gets called to retrieve the value of
fuse_current_so and setup the fusemod.
However, maybe it would be better to not use constructor functions at
all.  They might be called too soon (because of another modules'
dependencies, or LD_PRELOAD, ...) or called only once (we cannot put
the same library several times on the same stack).
Also, dlopen() being marked by libc as optimizable as "leaf", when you
compile FUSE with the default configure optimization option (-O2), the
setting of fuse_current_so to "so" (first line above) is optimized out
and removed from the generated code altogether. (This is the bug from
the previous mail).

Instead, using dlsym (or libltdl's equivalent) would remove the
constructor thing and replace it with a cleaner, explicit function
call.  Also, it would fix the previous mail's bug.

Do you see any drawbacks to changing the fusemod registration protocol
from constructor functions to dlsym calls?  I can work on implementing
it.

Thanks!

Best regards
Fabrice