From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: Questions about exportfs Date: Thu, 27 Nov 2008 23:20:28 +0000 Message-ID: <20081127232028.GE28946@ZenIV.linux.org.uk> References: <9428.1227797500@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org To: David Howells Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:45831 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752379AbYK0XUc (ORCPT ); Thu, 27 Nov 2008 18:20:32 -0500 Content-Disposition: inline In-Reply-To: <9428.1227797500@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Nov 27, 2008 at 02:51:40PM +0000, David Howells wrote: > > Hi Christoph, > > Can you answer some questions about exportfs please? > > (1) In linux/exportfs.h, the description of the encode_fh() op says that > "encode_fh() should return the number of bytes stored or a negative error > code such as %-ENOSPC". > > This, however, contradicts export_encode_fh(), which returns a member of > enum fid_type instead. I presume the docs are wrong, or at least, > unclear. No negative error codes, just 255 (or anything that would give 255 when converted to u8, actually). > (2) Why does exportfs_encode_fh() return the type of the FID? Why not embed > it in the fid struct? It seems that the value has to be handed back to > the decode routine. Take a look at the struct nfs_fhbase_new in include/linux/nfsd/nfsfh.h; we have type information for all components in the beginning, packed together, instead of embedding each into its part of array. > (3) Is fat_encode_fh() allowed to return a value not in the fid_type enum? Yes. That enum is just a bunch of common encoding schemes. The values you are using are entirely[*] up to specific filesystem; these ones are just for common helper functions. [*] other than "255 is reserved for encoding error"