From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: "Aneesh Kumar K. V"
<aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Ted Ts'o <tytso-3s7WtUTddSA@public.gmane.org>,
sfrench-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org,
agruen-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org,
dilger.kernel-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org,
sandeen-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH -V5 00/24] New ACL format for better NFSv4 acl interoperability
Date: Wed, 2 Mar 2011 13:58:47 -0500 [thread overview]
Message-ID: <20110302185847.GA3524@fieldses.org> (raw)
In-Reply-To: <87ei6pza5v.fsf-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On Wed, Mar 02, 2011 at 11:17:56PM +0530, Aneesh Kumar K. V wrote:
> On Wed, 2 Mar 2011 10:49:43 -0500, "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> wrote:
> > On Tue, Mar 01, 2011 at 12:20:36PM +0530, Aneesh Kumar K. V wrote:
> > > On Mon, 28 Feb 2011 16:11:45 -0500, "Ted Ts'o" <tytso-3s7WtUTddSA@public.gmane.org> wrote:
> > > > Hi Aneesh,
> > > >
> > > > What is the current status of this patch series? I seem to remember
> > > > that Christoph and Al Viro had some objections; have those been
> > > > cleared yet? If not, can you summarize what their objections are?
> > >
> > > The main objection raised was the use of may_delete and may_create inode
> > > operations callback. They are gone now and we have MAY_* flags as
> > > favoured by Al Viro. The new MAY_* flags added are
> > >
> > > #define MAY_CREATE_FILE 128
> > > #define MAY_CREATE_DIR 256
> > > #define MAY_DELETE_CHILD 512
> > > #define MAY_DELETE_SELF 1024
> > > #define MAY_TAKE_OWNERSHIP 2048
> > > #define MAY_CHMOD 4096
> > > #define MAY_SET_TIMES 8192
> > >
> > >
> > > >
> > > > To be honest I haven't been paying super close attention to this patch
> > > > series, and I'm curious what needs to happen with it one way or
> > > > another.
> > > >
> > >
> > > IMHO we are ready to get first 11 patches upstream in the next merge
> > > window. ie the below set of patches.
> >
> > Why aren't all of them ready?
> >
>
> All except how to enable richacl in local file system is ready. I
> actually floated two ideas in the patch series
>
> 1) mount option
> 2) Ext4 compat flags.
The choice of ACL format is a persistant property of the filesystem, not
of a single mount of the filesystem: for example, people can't try out
richacls for one mount and then decide to revert bacak to posix acls.
(Right?) So I'm assuming we should use the latter--but I don't
understand what ext4 compat flags are.... Is there some disadvantage to
using them?
--b.
>
> If we can get to decide which one, then the entire set can go in. We also
> want others to review the richacl format. If that cannot be completed by
> next merge window there is no reason to prevent the vfs changes from
> going in. VFS changes are independent of richacl format.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields@fieldses.org>
To: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: "Ted Ts'o" <tytso@mit.edu>,
sfrench@us.ibm.com, agruen@linbit.com, dilger.kernel@dilger.ca,
sandeen@redhat.com, jlayton@redhat.com,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -V5 00/24] New ACL format for better NFSv4 acl interoperability
Date: Wed, 2 Mar 2011 13:58:47 -0500 [thread overview]
Message-ID: <20110302185847.GA3524@fieldses.org> (raw)
In-Reply-To: <87ei6pza5v.fsf@linux.vnet.ibm.com>
On Wed, Mar 02, 2011 at 11:17:56PM +0530, Aneesh Kumar K. V wrote:
> On Wed, 2 Mar 2011 10:49:43 -0500, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > On Tue, Mar 01, 2011 at 12:20:36PM +0530, Aneesh Kumar K. V wrote:
> > > On Mon, 28 Feb 2011 16:11:45 -0500, "Ted Ts'o" <tytso@mit.edu> wrote:
> > > > Hi Aneesh,
> > > >
> > > > What is the current status of this patch series? I seem to remember
> > > > that Christoph and Al Viro had some objections; have those been
> > > > cleared yet? If not, can you summarize what their objections are?
> > >
> > > The main objection raised was the use of may_delete and may_create inode
> > > operations callback. They are gone now and we have MAY_* flags as
> > > favoured by Al Viro. The new MAY_* flags added are
> > >
> > > #define MAY_CREATE_FILE 128
> > > #define MAY_CREATE_DIR 256
> > > #define MAY_DELETE_CHILD 512
> > > #define MAY_DELETE_SELF 1024
> > > #define MAY_TAKE_OWNERSHIP 2048
> > > #define MAY_CHMOD 4096
> > > #define MAY_SET_TIMES 8192
> > >
> > >
> > > >
> > > > To be honest I haven't been paying super close attention to this patch
> > > > series, and I'm curious what needs to happen with it one way or
> > > > another.
> > > >
> > >
> > > IMHO we are ready to get first 11 patches upstream in the next merge
> > > window. ie the below set of patches.
> >
> > Why aren't all of them ready?
> >
>
> All except how to enable richacl in local file system is ready. I
> actually floated two ideas in the patch series
>
> 1) mount option
> 2) Ext4 compat flags.
The choice of ACL format is a persistant property of the filesystem, not
of a single mount of the filesystem: for example, people can't try out
richacls for one mount and then decide to revert bacak to posix acls.
(Right?) So I'm assuming we should use the latter--but I don't
understand what ext4 compat flags are.... Is there some disadvantage to
using them?
--b.
>
> If we can get to decide which one, then the entire set can go in. We also
> want others to review the richacl format. If that cannot be completed by
> next merge window there is no reason to prevent the vfs changes from
> going in. VFS changes are independent of richacl format.
next prev parent reply other threads:[~2011-03-02 18:58 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 13:51 [PATCH -V5 00/24] New ACL format for better NFSv4 acl interoperability Aneesh Kumar K.V
2011-02-23 13:51 ` [PATCH -V5 01/24] vfs: Indicate that the permission functions take all the MAY_* flags Aneesh Kumar K.V
[not found] ` <1298469131-16555-1-git-send-email-aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2011-02-23 13:51 ` [PATCH -V5 02/24] vfs: Pass all mask flags down to iop->check_acl Aneesh Kumar K.V
2011-02-23 13:51 ` Aneesh Kumar K.V
2011-02-23 13:51 ` [PATCH -V5 03/24] vfs: Add a comment to inode_permission() Aneesh Kumar K.V
2011-02-23 13:51 ` Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 14/24] richacl: Compute maximum file masks from an acl Aneesh Kumar K.V
2011-02-23 13:52 ` Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 15/24] richacl: Update the file masks in chmod() Aneesh Kumar K.V
2011-02-23 13:52 ` Aneesh Kumar K.V
2011-02-28 21:11 ` [PATCH -V5 00/24] New ACL format for better NFSv4 acl interoperability Ted Ts'o
2011-02-28 21:11 ` Ted Ts'o
2011-03-01 6:50 ` Aneesh Kumar K. V
2011-03-02 15:49 ` J. Bruce Fields
[not found] ` <20110302154943.GB29136-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2011-03-02 17:47 ` Aneesh Kumar K. V
2011-03-02 17:47 ` Aneesh Kumar K. V
[not found] ` <87ei6pza5v.fsf-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2011-03-02 18:58 ` J. Bruce Fields [this message]
2011-03-02 18:58 ` J. Bruce Fields
2011-03-04 10:38 ` Aneesh Kumar K. V
2011-03-05 0:32 ` J. Bruce Fields
[not found] ` <20110305003214.GF21260-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2011-03-05 17:58 ` Aneesh Kumar K. V
2011-03-05 17:58 ` Aneesh Kumar K. V
2011-03-15 8:46 ` Andreas Gruenbacher
2011-05-11 22:16 ` Björn JACKE
2011-05-11 22:16 ` Björn JACKE
2011-05-13 15:40 ` Aneesh Kumar K.V
2011-05-13 15:40 ` Aneesh Kumar K.V
2011-05-13 15:40 ` Aneesh Kumar K.V
[not found] ` <E1QKJAl-00DGc7-EB-dqLtpHMqGvUyWpdLl23E4A@public.gmane.org>
2011-05-13 15:40 ` Aneesh Kumar K.V
2011-05-11 22:16 ` Björn JACKE
2011-02-23 13:51 ` [PATCH -V5 04/24] vfs: Add generic IS_ACL() test for acl support Aneesh Kumar K.V
2011-02-23 13:51 ` [PATCH -V5 05/24] vfs: Add IS_RICHACL() test for richacl support Aneesh Kumar K.V
2011-02-23 13:51 ` [PATCH -V5 06/24] vfs: Optimize out IS_RICHACL() if CONFIG_FS_RICHACL is not defined Aneesh Kumar K.V
2011-02-23 13:51 ` [PATCH -V5 07/24] vfs: Add new file and directory create permission flags Aneesh Kumar K.V
2011-02-23 13:51 ` [PATCH -V5 08/24] vfs: Add delete child and delete self " Aneesh Kumar K.V
2011-02-23 13:51 ` [PATCH -V5 09/24] vfs: Make the inode passed to inode_change_ok non-const Aneesh Kumar K.V
2011-02-23 13:51 ` [PATCH -V5 10/24] vfs: Add permission flags for setting file attributes Aneesh Kumar K.V
2011-02-23 13:51 ` [PATCH -V5 11/24] vfs: Make acl_permission_check() work for richacls Aneesh Kumar K.V
2011-02-23 13:51 ` [PATCH -V5 12/24] richacl: In-memory representation and helper functions Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 13/24] richacl: Permission mapping functions Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 16/24] richacl: Permission check algorithm Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 17/24] richacl: Create-time inheritance Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 18/24] richacl: Check if an acl is equivalent to a file mode Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 19/24] richacl: Automatic Inheritance Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 20/24] richacl: xattr mapping functions Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 21/24] ext4: Use IS_POSIXACL() to check for POSIX ACL support Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 22/24] vfs: Cache richacl in struct inode Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 23/24] ext4: Implement rich acl for ext4 Aneesh Kumar K.V
2011-02-23 13:52 ` [PATCH -V5 24/24] ext4: Add temporary richacl mount option " 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=20110302185847.GA3524@fieldses.org \
--to=bfields-uc3wqj2krung9huczpvpmw@public.gmane.org \
--cc=agruen-63ez5xqkn6DQT0dZR+AlfA@public.gmane.org \
--cc=aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=dilger.kernel-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org \
--cc=jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sandeen-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=sfrench-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
--cc=tytso-3s7WtUTddSA@public.gmane.org \
/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.