[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3d3spvhdn.fsf@linux.vnet.ibm.com>
Date: Tue, 07 Sep 2010 18:29:48 +0530
From: "Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: hch@...radead.org, viro@...iv.linux.org.uk, adilger@....com,
corbet@....net, neilb@...e.de, npiggin@...nel.dk,
hooanon05@...oo.co.jp, bfields@...ldses.org, miklos@...redi.hu,
linux-fsdevel@...r.kernel.org, sfrench@...ibm.com,
philippe.deniel@....FR, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -V19 00/15] Generic name to handle and open by handle syscalls
On Tue, 07 Sep 2010 13:36:03 +0200, Miklos Szeredi <miklos@...redi.hu> 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
--
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