From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Aneesh Kumar K. V" Subject: Re: [PATCH -V19 00/15] Generic name to handle and open by handle syscalls Date: Tue, 07 Sep 2010 18:29:48 +0530 Message-ID: References: <1282906982-26918-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Cc: hch@infradead.org, viro@zeniv.linux.org.uk, adilger@sun.com, corbet@lwn.net, neilb@suse.de, npiggin@kernel.dk, hooanon05@yahoo.co.jp, bfields@fieldses.org, miklos@szeredi.hu, linux-fsdevel@vger.kernel.org, sfrench@us.ibm.com, philippe.deniel@CEA.FR, linux-kernel@vger.kernel.org To: Miklos Szeredi Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 07 Sep 2010 13:36:03 +0200, Miklos Szeredi wrote: > On Tue, 07 Sep 2010, Aneesh Kumar K. V wrote: > > Any update on this. Are you ok with syscall approach which is limitted to > > CAP_DAC_READ_SEARCH ? > > My gut reaction is: "not another bunch of xattr syscalls!". It > doesn't feel right, this interface is too specialized to warrant a > full set of filesystem syscalls. Are you ok with rest of syscalls other than the handle based xattr one ? In that case can we get rest of the patches merged and rework xattr patches later ?. That is xattr support for symlink can follow as a separate patch series ? > > Al Viro is right that there are problems with symlinks. What we > really want here is a sort of symlink that doesn't get followed. One > way to provide that is to create a kernel internal "handle" filesystem > and direct open_by_handle() to that for anything not a directory or a > regular file. > -aneesh