Hi Florian,

...

For porting FUSE, the author uses a library called "libfs" which provides filesystem request forwarding and processing, if I understood correctly. It reads as if libfs is already included in L4Re. However, I couldn't find neither FUSE nor libfs in the current L4Re snapshot. Are they by any chance publicly available somewhere else, or are both not to be published?

They are not in the public SVN as of now, but I packed them for you and put the tarball to:

https://os.inf.tu-dresden.de/~fpester/fuse-l4re.tar.gz

thank you very much! I really appreciate your effort and your work. So as it seems to me, libfs was never an "official" part of L4Re. But where did it come from? Was it part of another thesis?

If you have any further questions, please feel free to ask.

thanks!

Josef

Hello,

https://os.inf.tu-dresden.de/~fpester/fuse-l4re.tar.gz

so I was able to get the provided version of libfs to compile on the latest snapshot of L4Re simply by changing "L4::Server_object_t<L4fs>" to "L4::Server_object" (line 40 in libfs/include/svr.h).

However, I am not sure if that was the right thing to do, but I wasn't able to test it since I don't know how to use libfs.

By the way: What I want to get is a machine-global temporary file system using tmpfs and libfs.

I think that the client simply needs to be linked with "libl4revfs-fs-l4fs" and then do a mount call with "l4fs" as the fs type and the same mount path that the server uses (or use libmount accordingly).

But I have no clue about the server. It most probably also needs to be linked with the respective library ("libfs-svr") but I think that's not enough. I guess the messages explicitly must be forwarded to the target file system. If this is right, again I don't know how to do it, since the server (which mounts the tmpfs) receives VFS calls over IPC but has no direct access to the VFS "interface" of the tmpfs, only the standard (POSIX?) functions like fopen(), fclose(), fread() etc.

I am a bit lost here, so I would really appreciate any help.

Also,

It exists in the internal tree, it was just never promoted to go public.

does this mean that at one point there was a version of libfs that worked but wasn't continued and thus doesn't work on the current snapshot anymore, or is libfs still being maintained and just not present in the public tree?

Thanks.

Sincerely, Josef

Hey,

sorry for the long wait.

No worries. I appreciate that you (and the other hackers) spend some of their spare time here helping people like me. Didn't have much time myself lately anyway.

I also ported fuse-exfat (read: adjusted the Makefile to compile it). You can find that here: http://os.inf.tu-dresden.de/~fpester/fuse-exfat-l4re.zip

Thanks again.

However, I'm having some trouble preparing the basics: (Both issues refer to your first answer and the archive you linked to there)

1.

In any case, you probably have to apply the patch files located in the doc/ directory of fuse-l4re to libfs. I dimly remember having some weird bugs without those.

The patches in the archive don't seem to be for the version of libfs that is contained in it, as I cannot patch without errors. (I managed, however, to compile it. See my last mail. Not sure if it'd work though.) So there seems to be at least one other version of libfs. Could you possibly provide a more recent (best case: the most recent) version of libfs?

2. I failed to compile fuse-l4re. I tried it in SVN revisions r44 and r54; both revisions should be from about the time when you wrote your Beleg. The error was always that sys/statvfs.h was missing. When compiled with this workaround (http://stackoverflow.com/a/12623828) the compiler complains that some attribute of a struct is missing, so this seems like the wrong way to go. The strange thing is that statvfs.h is actually there, somewhere in uclibc (src/l4/pkg/uclibc/lib/contrib/uclibc/include/sys/) but it's not copied into the global include file directory of the L4Re build directory. Did you back then change the config of uclibc and/or L4Re to achieve a successful compilation?

Thank you in advance, Josef