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.
next prev parent 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: linkBe 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.