[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegt94fP-_eDAk=_C=24ahCtjQ4vhh8Xg+SrZbwPHs1waLA@mail.gmail.com>
Date: Tue, 10 May 2022 16:41:35 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Christian Brauner <brauner@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, Dave Chinner <david@...morbit.com>,
"Theodore Ts'o" <tytso@....edu>, Karel Zak <kzak@...hat.com>,
Greg KH <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org,
Linux API <linux-api@...r.kernel.org>,
linux-man <linux-man@...r.kernel.org>,
LSM <linux-security-module@...r.kernel.org>,
Ian Kent <raven@...maw.net>,
David Howells <dhowells@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <christian@...uner.io>,
Amir Goldstein <amir73il@...il.com>,
James Bottomley <James.Bottomley@...senpartnership.com>
Subject: Re: [RFC PATCH] getting misc stats/attributes via xattr API
On Tue, 10 May 2022 at 16:19, Christian Brauner <brauner@...nel.org> wrote:
> Fwiw, turning this around: unifying semantically distinct interfaces
> because of syntactical similarities is bad. Moving them into a
> syntactically equivalent system call that expresses the difference in
> semantics in its name is good.
You are ignoring the arguments against fragmentation.
You are also ignoring the fact that semantically the current xattr
interface is already fragmented. Grep for "strncmp(name, XATTR_" in
fs/xattr.c.
We don't have getsecurityxattr(), getuserxattr(), gettrustedxattr()
and getsystemxattr(). It would be crazy. Adding getfsxattr() would
be equally crazy. getxattr() pretty much describes the semantics of
all of these things.
Thanks,
Miklos
Powered by blists - more mailing lists