Re: [PATCH 3/4] FUSE: implement fuse_req->prep()

[Tejun Heo <tj@kernel.org>]

Hello,

Andrew Morton wrote:
> On Thu, 18 Jun 2009 18:24:32 +0900
> Tejun Heo <tj@kernel.org> wrote:
> 
>> Implement ->prep() which is the opposite equivalent of ->end().
> 
> The opposite of "end" is "begin".  I'd expect to see a sequence like
> 
> 	-> prep
> 	-> begin
> 	-> end
> 
> so the naming choice here is unexpected.

Yes, indeed.  I'll look for a better name.

>>  It's
>> called right before the request is passed to userland server in the
>> kernel context of the server.  ->prep() can fail the request without
>> disrupting the whole channel.
>>
>> This will be used by direct mmap implementation.
> 
>> ...
>>
>> --- a/fs/fuse/fuse_i.h
>> +++ b/fs/fuse/fuse_i.h
>> @@ -292,6 +292,12 @@ struct fuse_req {
>>  	/** Link on fi->writepages */
>>  	struct list_head writepages_entry;
>>  
>> +	/** Request preparation callback.  Called from the kernel
>> +	    context of the FUSE server before passing the request to
>> +	    the FUSE server.  Non-zero return from this function will
>> +	    fail the request. */
>> +	int (*prep)(struct fuse_conn *, struct fuse_req *);
>> +
>>  	/** Request completion callback.  This function is called from
>>  	    the kernel context of the FUSE server if the request isn't
>>  	    being aborted.  If the request is being aborted, it's
> 
> Why the strange comment layout?  Does kerneldoc actually recognise and
> appropriately process this text?  if not, please do
> 
> 	/*
> 	 * Request preparation callback.  Called from the kernel
> 	 * context of the FUSE server before passing the request to
> 	 * the FUSE server.  Non-zero return from this function will
> 	 * fail the request.
> 	 */
> 
> If that looks odd then, well, that wasn't your fault ;)

I usually try to conform to the surrounding style so that new stuff at
least is consistent with the rest (and maintainers tend to feel
happier that way) but yeah this can cause confusion to kerneldoc
handling.  I'll add a patch to change the style.

Thanks.

-- 
tejun