[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klik-devel
Subject:    [klik-devel] FUSE CLONE_NEWNS implementation ...
From:       "Fabian Franz" <FabianFranz () gmx ! de>
Date:       2007-02-24 4:27:40
Message-ID: 20070224042740.236220 () gmx ! net
[Download RAW message or body]

So,

here we go. The newest release of klik-overlay has seamless fuse support in addtition \
to real unionfs like aufs or unionfs.

It ships a custom funionfs_klik binary (570k though), which is statically linked \
against a slightly patched fuse library, so it should run everywhere. (Thanks lionel \
for the idea)

(suid binary can be rebuild via Makefile if needed.)

Same instructions for installation as before do apply, but it now "magically" ;) \
works also on just "fuse" systems.

Module preference is: aufs,fuse,unionfs

For fuse, fusermount needs to be present in root's path. I could perhaps just ship \
for that a static renamed binary as well.

Get it from:

http://studwww.ira.uka.de/~s_franz2/klik/

Installation instructions for .klik/.zAppRun are the same as can be found in above \
README. Again old .cmgs will work exactly like new .cmgs.

So that whole thing should just work.

Regarding performance:

OO 2.1 normal start: 0m4.587s
OO 2.1 fuse/funionfs start: 0m5.757s

And one sec for such a big binary doesn't seem too bad.

Changes to libfuse:

If you wonder what I had to change in libfuse:

I changed it so that the fuse server can be spawned outside of the new namespace \
while the mount is done inside.

Instead of spawning fusermount my fuse library just gets the real FD from environment \
/ suid_binary.

See klik-overlay*.tar.gz/patches/*.

cu

Fabian

PS: So probono you can put a only standard kernel modules='yes' in the overview table \
now. :) _______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel


[prev in list] [next in list] [prev in thread] [next in thread]