Re: [PATCHSET] CUSE: implement CUSE, take #3

[Tejun Heo <tj@kernel.org>]

Hello,

Miklos Szeredi wrote:
> Hello Tejun,
> 
> Sorry for the delay, I was busy reimplementing some of the stuff in
> your patchset.  The current state is here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git cuse-test
> 
>   http://git.kernel.org/?p=linux/kernel/git/mszeredi/fuse.git;a=shortlog;h=cuse-test
> 
> What I changed (IIRC):
> 
>  - Don't store pointer to struct inode, struct fuse_inode, and struct
>    file in struct fuse_file.  Instead store nodeid in struct
>    fuse_file, no worries about object lifetimes this way.

Hmm... there really isn't any object lifetime issue with or without
the pointers as both fuse_file and fuse_inode follow VFS lifetime
rules.  I tried several different approaches including adding nodeid
but what pushed me toward adding the pointers was that the parameter
passing and which uses/depends on what becomes a bit too complex with
other approaches.  e.g. How do you discern between needing vfs inode
and fuse inode?

>  - Don't implement fsync and flush in CUSE, they don't really make
>    sense on character devices.  At least I can't think of any use for
>    them.
>  - release() in CUSE can be synchronous.  Asynchronous release causes
>    many headaches in fuse, but is necessary due to the possible DoS
>    that an unprivileged filesystem could do with an unrelated process.
>    Since CUSE servers are always privileged, this should not be an
>    issue.

Cool.

>  - Other cleanups.
> 
> I still think that the INIT sequence in CUSE is way too complicated
> and that the kernel thread is unnecessary.  How about doing the init
> with a single CUSE_INIT message which embeds the fuse_init_in and
> fuse_init_out structures.

I don't see why the kernel thread is such a big problem.  It's just a
kernel thread.  We can surely fold FUSE_INIT inside FUSE_INIT tho but
one way or the other doesn't make whole lot of difference.

> I also don't see the purpose of the CUSE_INIT_DONE message.  Isn't
> it enough not to send any other messages while the initialization is
> not complete?  This is what fuse does.

The difference between FUSE and CUSE in this regard is that the
synchornous part of initialization is much less for CUSE.  ie. For
FUSE, after the mount is complete, all accesses go to FUSE, so it's
all good.  However, for CUSE, the device nodes are setup
asynchronously, so there's no such inherent synchronization point as
mount.  This becomes a problem when CUSE is started from modprobe to
emulate devices on demand because modprobe should not return before
the device nodes are setup.

Thanks.

-- 
tejun