lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 24 Jun 2009 09:07:55 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	linux-kernel@...r.kernel.org, fuse-devel@...ts.sourceforge.net,
	miklos@...redi.hu, npiggin@...e.de
Subject: Re: [PATCH 3/4] FUSE: implement fuse_req->prep()

Hello,

Andrew Morton wrote:
> On Thu, 18 Jun 2009 18:24:32 +0900
> Tejun Heo <tj@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists