Hello Zdenek,
I managed to made FUSE Hello world low level example (fuse-2.9.0/example/hellow_ll.c) working as fusehell* fs server.
Nice. :)
Interface choice ---------------- 2) Low level API (fuse_lowlevel.h) - just like any other filesystem in HelenOS - vfs_out_ops_t and libfs_ops_t functions are almost directly calling fuse_lowlevel_ops functions - Reply (fuse_reply_*) is stored in req (fuse_req_t). - fuse_path_ops from FUSe library could be used for high level api. - simplified readonly prototype: https://code.launchpad.net/~zdenek-bouska/helenos/fuse
In my opinion this is a reasonable pragmatic solution. I believe that this layer is also used by other FUSE implementations (FUSE for Mac OS X, FUSE for FreeBSD, FUSE for Solaris), or am I mistaken?
3) Kernel interface messages - struct fuse_chan_ops could be used for this. - It would require porting of almost whole FUSE library. - fuse upgrades could be easier - There is one unnecessary layer. - I'm not sure if this would be possible without some FUSE server. That would mean another IPC messages.
Having a dedicated FUSE server has some appeal, you might think about connecting a FUSE client running in Linux to the HelenOS FUSE server (say through a paravirtualized interface or over network). But still, I would choose the option 2) for practical purposes.
Dealing with POSIX ------------------ FUSE is using POSIX stat struct. Most of FUSE filesystem is using some POSIX stuff (like string.h) I haven't dealt with this yet. I just made some modifications to hello_ll.c and POSIX structs and constants are temporary in uspace/lib/fs/fuse_posix.h I will probably move the whole fuse library to uspace/lib/posix/. I don't think of a reason for native FUSE filesystem in HelenOS: either it is supposed to be portable or you could use just libfs.
Yes, this sounds reasonable to me. M.D. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
