All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
To: Neil Brown <neilb@suse.de>
Cc: hch@infradead.org, viro@zeniv.linux.org.uk, adilger@sun.com,
	corbet@lwn.net, serue@us.ibm.com, hooanon05@yahoo.co.jp,
	bfields@fieldses.org, linux-fsdevel@vger.kernel.org,
	sfrench@us.ibm.com, philippe.deniel@CEA.FR,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH -V14 0/11] Generic name to handle and open by handle syscalls
Date: Fri, 02 Jul 2010 02:45:45 +0530	[thread overview]
Message-ID: <87iq4y29a6.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100702064108.64034561@notabene.brown>

On Fri, 2 Jul 2010 06:41:08 +1000, Neil Brown <neilb@suse.de> wrote:
> On Thu, 01 Jul 2010 21:58:54 +0530
> "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> 
> > On Tue, 15 Jun 2010 22:42:50 +0530, "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > 
> > Hi Al,
> > 
> > Any chance of getting this reviewed/merged in the next merge window ?
> 
>  My own opinion of the patchset is that the code itself is fine,
>  however there is one part of the interface that bothers me.
> 
>  I think that it is a little ugly that filesystem uuid extraction is so
>  closely tied to filehandle manipulation.  They are certainly related, and we
>  certainly need to be able to get the filesystem uuid directly from the
>  filesystem, but given that filehandle -> fd mapping doesn't (and shouldn't)
>  use the uuid, the fact that fd/name -> filehandle mapping does return the
>  uuid looks like it is simply piggy backing some functionality on the side,
>  rather than creating a properly designed and general interface.
> 
>  I would feel happier about the patches if you removed all reference to uuids
>  and then found some other way to ask a filesystem what its uuid was.
> 
>  This is not an issue that would make be want to stop the patches going
>  upstream, but it does hold me back from offering a reviewed-by or
>  acked-by (for whatever they might be worth).
> 

One use case i had was that if the userspace file server can directly work
with the returned file system UUID, the it can build the file handle for client
in a single call.


-aneesh

  reply	other threads:[~2010-07-01 21:25 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-15 17:12 [PATCH -V14 0/11] Generic name to handle and open by handle syscalls Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 01/11] exportfs: Return the minimum required handle size Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 02/11] vfs: Add name to file handle conversion support Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 03/11] vfs: Add open by file handle support Aneesh Kumar K.V
2010-07-07 15:17   ` Nick Piggin
2010-07-07 16:16     ` Aneesh Kumar K. V
2010-06-15 17:12 ` [PATCH -V14 04/11] vfs: Allow handle based open on symlinks Aneesh Kumar K.V
2010-07-07 15:23   ` Nick Piggin
2010-07-07 16:24     ` Aneesh Kumar K. V
2010-07-07 16:57       ` Nick Piggin
2010-07-07 17:53         ` Aneesh Kumar K. V
2010-07-07 18:20           ` Nick Piggin
2010-07-07 16:48   ` Nick Piggin
2010-07-08 10:42     ` Aneesh Kumar K. V
2010-06-15 17:12 ` [PATCH -V14 05/11] vfs: Support null pathname in readlink Aneesh Kumar K.V
2010-07-07 15:27   ` Nick Piggin
2010-07-07 16:32     ` Aneesh Kumar K. V
2010-07-07 17:03       ` Nick Piggin
2010-06-15 17:12 ` [PATCH -V14 06/11] ext4: Copy fs UUID to superblock Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 07/11] x86: Add new syscalls for x86_32 Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 08/11] x86: Add new syscalls for x86_64 Aneesh Kumar K.V
2010-06-15 17:12 ` [PATCH -V14 09/11] ext3: Copy fs UUID to superblock Aneesh Kumar K.V
2010-06-15 17:13 ` [PATCH -V14 10/11] vfs: Support null pathname in faccessat Aneesh Kumar K.V
2010-06-15 17:13 ` [PATCH -V14 11/11] vfs: Support null pathname in linkat Aneesh Kumar K.V
2010-07-01 16:28 ` [PATCH -V14 0/11] Generic name to handle and open by handle syscalls Aneesh Kumar K. V
2010-07-01 20:41   ` Neil Brown
2010-07-01 21:15     ` Aneesh Kumar K. V [this message]
2010-07-06 16:10       ` J. Bruce Fields
2010-07-06 17:09         ` Aneesh Kumar K. V
2010-07-06 23:23           ` Dave Chinner
2010-07-06 23:36             ` Neil Brown
2010-07-07  2:11               ` Dave Chinner
2010-07-07  2:57                 ` Neil Brown
2010-07-07 12:44                   ` Miklos Szeredi
2010-07-07 12:57                   ` J. Bruce Fields
2010-07-07 13:10                     ` Miklos Szeredi
2010-07-07 13:17                       ` J. Bruce Fields
2010-07-07 13:35                         ` Miklos Szeredi
2010-07-07 14:45                           ` J. Bruce Fields
2010-07-07 16:33                             ` Aneesh Kumar K. V
2010-07-07 16:39                               ` J. Bruce Fields
2010-07-07 22:21                             ` Neil Brown
2010-07-07 22:25                               ` J. Bruce Fields
2010-07-08  0:03                               ` Andreas Dilger
2010-07-08  5:03                                 ` Neil Brown
2010-07-08 10:40                               ` Aneesh Kumar K. V
2010-07-08 11:52                                 ` Miklos Szeredi
2010-07-08 12:21                                 ` Neil Brown
2010-07-09 18:42                                   ` Andreas Dilger
2010-07-09 18:42                                     ` Andreas Dilger
2010-07-10  4:58                                     ` Aneesh Kumar K. V
2010-07-10  4:58                                       ` Aneesh Kumar K. V
2010-07-07  7:40           ` Andreas Dilger
2010-07-07 15:05             ` J. Bruce Fields
2010-07-07 17:02               ` Andreas Dilger
2010-07-07 17:37                 ` J. Bruce Fields
2010-07-07 18:05                 ` Nick Piggin
2010-07-07 23:49                   ` Andreas Dilger
2010-07-07 23:49                     ` Andreas Dilger
2010-07-07 18:18                 ` Aneesh Kumar K. V
2010-07-07 20:39                 ` Alan Cox
2010-07-07 23:54                   ` Andreas Dilger
2010-07-07 23:54                     ` Andreas Dilger
2010-07-02  4:02     ` Andreas Dilger
2010-07-02  7:05       ` hch
2010-07-02 16:12         ` Andreas Dilger
2010-07-02 22:09           ` Neil Brown
2010-07-02 22:47             ` Andreas Dilger
2010-07-03 16:04             ` Aneesh Kumar K. V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87iq4y29a6.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=adilger@sun.com \
    --cc=bfields@fieldses.org \
    --cc=corbet@lwn.net \
    --cc=hch@infradead.org \
    --cc=hooanon05@yahoo.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=philippe.deniel@CEA.FR \
    --cc=serue@us.ibm.com \
    --cc=sfrench@us.ibm.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.