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

[Tejun Heo]

Hello,

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.

>>> 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.
> 
> I think it's an unnecessary complication.  Threads are useful if
> something needs to be _done_, but in this case nothing is done, just
> waiting for the reply.  One example why I find it hackish is that you
> are returning error values from the thread, as if it was a synchronous
> thing, but those errors are obviously lost.

That doesn't have anything to do with whether it's done in kernel
thread or not.  If that bothers you, just make it return 0 with
comment /* return value ignored */.

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

In my first job, I used to work on a quite complex state machine based
server which had to do almost everything in multiple functions.  In
the end, it was extremely ugly and ultimately the wrong kind of
optimization, so I much prefer having a stack whenever it makes things
simpler and the overhead isn't an issue.  What are the actual benefits
of doing things in several different functions in this case?
Performance definitely is not a concern here.

>>  We can surely fold FUSE_INIT inside FUSE_INIT tho but
>> one way or the other doesn't make whole lot of difference.
> 
> I just think it would be cleaner, both code-wise and protocol-wise.  I
> can do the above cleanups if you have no objection.

Sure, if you think things would be better that way.  Please go ahead.

Thanks.

-- 
tejun
--
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/