lkml.org 
[lkml]   [2009]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCHSET] CUSE: implement CUSE, take #3
From
Date
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.

- 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.

- 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 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.

I'm currently testing with ossp and some things do work, but I'm also
having issues with some apps. But that's a topic for another mail...

Thanks,
Miklos


\
 
 \ /
  Last update: 2009-04-22 13:43    [W:0.077 / U:1.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site