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

[Miklos Szeredi]

Hi Tejun,

On Thu, 23 Apr 2009, Tejun Heo wrote:
> Miklos Szeredi wrote:
> > VFS inode should never be needed by the CUSE codepaths.  Well, maybe
> > for setting access/modification times, but in any case those need not
> > be shared with fuse code.
> 
> One more usage: locking.

You mean inode->i_mutex locking?  It doesn't look to me as if cuse
would need to do any of that.

> > I don't see any problems with doing the device initialization in the
> > context of the replying process (which will usually be the same as
> > the one opening the device anyway).
> 
> I don't know.  If it's simple, sure why not.  If it makes things even
> marginally more complex (state saving and so on), why go that way?

OK, I folded FUSE_INIT into CUSE_INIT, and moved the CUSE_INIT reply
processing into the ->end() callback.  This also allows us to remove
the CUSE_INIT_DONE message, since now the write(2) on the cuse device
will only return when the device initialization is complete.

Overall it results in some 100 lines less code (well, some of that is
because I folded <linux/cuse.h> into <linux/fuse.h>).  But the simpler
initialization sequence is, I think, definitely worth it.

The patches are pushed out to the 'cuse' and 'for-next' branches of

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git

I'll post the updated libfuse patch as well.  Please let me know if
you find anything wrong with the current patches.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/