All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-fsdevel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
	Seth Forshee <sforshee@kernel.org>,
	linux-erofs@lists.ozlabs.org
Subject: Re: [PATCH 05/12] erofs: drop posix acl handlers
Date: Mon, 30 Jan 2023 10:11:32 +0100	[thread overview]
Message-ID: <20230130091132.GA5178@lst.de> (raw)
In-Reply-To: <20230130090008.zg5ddfanrgeommrv@wittgenstein>

On Mon, Jan 30, 2023 at 10:00:08AM +0100, Christian Brauner wrote:
> > > +	if (xattr_dentry_list(handler, dentry))
> > > +		name = xattr_prefix(handler);
> > 
> > I'm not a huge fan of all this duplicate logic in the file systems
> > that is more verbose and a bit confusing.  Until we remove the
> 
> Yeah, it hasn't been my favorite part about this either.
> But note how the few filesystems that receive that change use the same
> logic by indexing an array and retrieving the handler and then clumsily
> open-coding the same check that is now moved into xattr_dentry_list().

At least it allows for an array lookup.  And of course switching
to xattr_dentry_list instead of open coding it is always a good idea.

> If we want the exact same logic to be followed as today then we need to
> keep the dummy struct posix_acl_{access,default}_xattr_handler around.
> I tried to avoid that for the first version because it felt a bit
> disappointing but we can live with this. This way there's zero code changes
> required for filesystems that use legacy array-based handler-indexing.

Yes, I'd just leave those as-is using the handlers.  I don't really
like the result, but the changes in the series doesn't really look
better and causes extra churn.  In the long run struct xattr_handler
needs to go away and we'll need separate handlers for each type
of xattrs, but that's going to take a while.  Do you know where the
capabilities conversion is standing?

> But we should probably still tweak this so that all these filesystems don't
> open-code the !h || (h->list && !h->list(dentry) check like they do now. So
> something like what I did below at [1]. Thoughts?

Yes, that part is useful.

> +static inline const char *erofs_xattr_prefix(unsigned int idx, struct dentry *dentry)

Overly long line here, though.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Christian Brauner <brauner@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Seth Forshee <sforshee@kernel.org>,
	linux-erofs@lists.ozlabs.org, Christoph Hellwig <hch@lst.de>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 05/12] erofs: drop posix acl handlers
Date: Mon, 30 Jan 2023 10:11:32 +0100	[thread overview]
Message-ID: <20230130091132.GA5178@lst.de> (raw)
In-Reply-To: <20230130090008.zg5ddfanrgeommrv@wittgenstein>

On Mon, Jan 30, 2023 at 10:00:08AM +0100, Christian Brauner wrote:
> > > +	if (xattr_dentry_list(handler, dentry))
> > > +		name = xattr_prefix(handler);
> > 
> > I'm not a huge fan of all this duplicate logic in the file systems
> > that is more verbose and a bit confusing.  Until we remove the
> 
> Yeah, it hasn't been my favorite part about this either.
> But note how the few filesystems that receive that change use the same
> logic by indexing an array and retrieving the handler and then clumsily
> open-coding the same check that is now moved into xattr_dentry_list().

At least it allows for an array lookup.  And of course switching
to xattr_dentry_list instead of open coding it is always a good idea.

> If we want the exact same logic to be followed as today then we need to
> keep the dummy struct posix_acl_{access,default}_xattr_handler around.
> I tried to avoid that for the first version because it felt a bit
> disappointing but we can live with this. This way there's zero code changes
> required for filesystems that use legacy array-based handler-indexing.

Yes, I'd just leave those as-is using the handlers.  I don't really
like the result, but the changes in the series doesn't really look
better and causes extra churn.  In the long run struct xattr_handler
needs to go away and we'll need separate handlers for each type
of xattrs, but that's going to take a while.  Do you know where the
capabilities conversion is standing?

> But we should probably still tweak this so that all these filesystems don't
> open-code the !h || (h->list && !h->list(dentry) check like they do now. So
> something like what I did below at [1]. Thoughts?

Yes, that part is useful.

> +static inline const char *erofs_xattr_prefix(unsigned int idx, struct dentry *dentry)

Overly long line here, though.

  reply	other threads:[~2023-01-30  9:11 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 11:28 [f2fs-dev] [PATCH 00/12] acl: remove remaining posix acl handlers Christian Brauner
2023-01-25 11:28 ` Christian Brauner
2023-01-25 11:28 ` [Ocfs2-devel] " Christian Brauner via Ocfs2-devel
2023-01-25 11:28 ` Christian Brauner
2023-01-25 11:28 ` Christian Brauner
2023-01-25 11:28 ` Christian Brauner
2023-01-25 11:28 ` [PATCH 01/12] xattr: simplify listxattr helpers Christian Brauner
2023-01-30  6:35   ` Christoph Hellwig
2023-01-25 11:28 ` [PATCH 02/12] xattr, posix acl: add " Christian Brauner
2023-01-30  6:37   ` Christoph Hellwig
2023-01-25 11:28 ` [PATCH 03/12] xattr: remove unused argument Christian Brauner
2023-01-30  6:37   ` Christoph Hellwig
2023-01-25 11:28 ` [PATCH 04/12] fs: drop unused posix acl handlers Christian Brauner
2023-01-30  6:38   ` Christoph Hellwig
2023-01-25 11:28 ` [PATCH 05/12] erofs: drop " Christian Brauner
2023-01-25 11:28   ` Christian Brauner
2023-01-30  6:43   ` Christoph Hellwig
2023-01-30  6:43     ` Christoph Hellwig
2023-01-30  9:00     ` Christian Brauner
2023-01-30  9:00       ` Christian Brauner
2023-01-30  9:11       ` Christoph Hellwig [this message]
2023-01-30  9:11         ` Christoph Hellwig
2023-01-25 11:28 ` [PATCH 06/12] ext2: " Christian Brauner
2023-01-25 13:03   ` Jan Kara
2023-01-25 11:28 ` [PATCH 07/12] ext4: " Christian Brauner
2023-01-25 11:28 ` [f2fs-dev] [PATCH 08/12] f2fs: " Christian Brauner
2023-01-25 11:28   ` Christian Brauner
2023-01-25 11:28 ` [PATCH 09/12] jffs2: " Christian Brauner
2023-01-25 11:28   ` Christian Brauner
2023-01-25 11:28 ` [PATCH 10/12] ocfs2: " Christian Brauner
2023-01-25 11:28   ` [Ocfs2-devel] " Christian Brauner via Ocfs2-devel
2023-01-25 11:28 ` [PATCH 11/12] reiserfs: " Christian Brauner
2023-01-25 11:28 ` [PATCH 12/12] acl: remove " Christian Brauner
2023-01-31 12:04   ` kernel test robot
2023-01-30  9:10 ` [PATCH 00/12] acl: remove remaining " Christian Brauner
2023-01-30  9:10   ` Christian Brauner
2023-01-30  9:10   ` [f2fs-dev] " Christian Brauner
2023-01-30  9:10   ` Christian Brauner
2023-01-30  9:10   ` [Ocfs2-devel] " Christian Brauner via Ocfs2-devel
2023-01-30  9:16   ` Christoph Hellwig
2023-01-30  9:16     ` Christoph Hellwig
2023-01-30  9:16     ` Christoph Hellwig
2023-01-30  9:16     ` [f2fs-dev] " Christoph Hellwig
2023-01-30  9:16     ` [Ocfs2-devel] " Christoph Hellwig via Ocfs2-devel
2023-01-30 10:23     ` Christian Brauner
2023-01-30 10:23       ` Christian Brauner
2023-01-30 10:23       ` Christian Brauner
2023-01-30 10:23       ` [f2fs-dev] " Christian Brauner
2023-01-30 10:23       ` [Ocfs2-devel] " Christian Brauner via Ocfs2-devel

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=20230130091132.GA5178@lst.de \
    --to=hch@lst.de \
    --cc=brauner@kernel.org \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sforshee@kernel.org \
    --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.