From: Vivek Goyal <vgoyal@redhat.com>
To: Christian Brauner <brauner@kernel.org>
Cc: Amir Goldstein <amir73il@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Dave Chinner <david@fromorbit.com>, Theodore Ts'o <tytso@mit.edu>,
Karel Zak <kzak@redhat.com>, Greg KH <gregkh@linuxfoundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
linux-man <linux-man@vger.kernel.org>,
LSM <linux-security-module@vger.kernel.org>,
Ian Kent <raven@themaw.net>, David Howells <dhowells@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <christian@brauner.io>,
James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [RFC PATCH] getting misc stats/attributes via xattr API
Date: Mon, 9 May 2022 17:42:41 -0400 [thread overview]
Message-ID: <YnmK0VJhQ4sf8AMI@redhat.com> (raw)
In-Reply-To: <20220509150856.cfsxn5t2tvev2njx@wittgenstein>
On Mon, May 09, 2022 at 05:08:56PM +0200, Christian Brauner wrote:
[..]
> Having "xattr" in the system call name is just confusing. These are
> fundamentally not "real" xattrs and we shouldn't mix semantics. There
> should be a clear distinction between traditional xattrs and this vfs
> and potentially fs information providing interface.
>
> Just thinking about what the manpage would look like. We would need to
> add a paragraph to xattr(7) explaining that in addition to the system.*,
> security.*, user.* and other namespaces we now also have a set of
> namespaces that function as ways to get information about mounts or
> other things instead of information attached to specific inodes.
>
> That's super random imho. If I were to be presented with this manpage
> I'd wonder if someone was too lazy to add a proper new system call with
> it's own semantics for this and just stuffed it into an existing API
> because it provided matching system call arguments. We can add a new
> system call. It's not that we're running out of them.
FWIW, I also felt that using xattr API to get some sort of mount info felt
very non-intutive.
Thanks
Vivek
next prev parent reply other threads:[~2022-05-09 21:43 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 12:23 [RFC PATCH] getting misc stats/attributes via xattr API Miklos Szeredi
2022-05-03 14:39 ` Amir Goldstein
2022-05-03 14:53 ` Greg KH
2022-05-03 15:04 ` Miklos Szeredi
2022-05-03 15:14 ` Amir Goldstein
2022-05-03 16:54 ` Greg KH
2022-05-03 22:43 ` Dave Chinner
2022-05-04 7:18 ` Miklos Szeredi
2022-05-04 14:22 ` Amir Goldstein
2022-05-05 12:30 ` Karel Zak
2022-05-05 13:59 ` Miklos Szeredi
2022-05-05 23:38 ` tytso
2022-05-06 0:06 ` Amir Goldstein
2022-05-07 0:32 ` Dave Chinner
2022-05-09 12:48 ` Christian Brauner
2022-05-09 14:20 ` Amir Goldstein
2022-05-09 15:08 ` Christian Brauner
2022-05-09 17:07 ` Amir Goldstein
2022-05-09 21:42 ` Vivek Goyal [this message]
2022-05-10 3:34 ` Ian Kent
2022-05-10 0:55 ` Dave Chinner
2022-05-10 12:40 ` Christian Brauner
2022-05-11 0:42 ` Dave Chinner
2022-05-11 9:16 ` Christian Brauner
2022-05-10 12:45 ` Florian Weimer
2022-05-10 23:04 ` Dave Chinner
2022-05-10 3:49 ` Miklos Szeredi
2022-05-10 4:27 ` Ian Kent
2022-05-10 8:06 ` Miklos Szeredi
2022-05-10 8:07 ` Miklos Szeredi
2022-05-10 11:53 ` Christian Brauner
2022-05-10 13:15 ` Miklos Szeredi
2022-05-10 13:18 ` Miklos Szeredi
2022-05-10 14:19 ` Christian Brauner
2022-05-10 14:41 ` Miklos Szeredi
2022-05-10 15:30 ` Christian Brauner
2022-05-10 15:47 ` Miklos Szeredi
2022-05-10 15:53 ` Christian Brauner
2022-05-10 12:35 ` Karel Zak
2022-05-10 23:25 ` Dave Chinner
2022-05-11 8:58 ` Karel Zak
2022-11-14 9:00 ` Abel Wu
2022-11-14 12:35 ` Miklos Szeredi
2022-11-15 3:39 ` Abel Wu
2023-04-15 11:06 ` [LSF/MM TOPIC] fsinfo and mount namespace notifications Amir Goldstein
2023-04-18 8:54 ` Miklos Szeredi
2023-04-18 15:56 ` Amir Goldstein
2023-04-18 18:57 ` Miklos Szeredi
2023-04-19 8:18 ` Amir Goldstein
2023-04-19 8:43 ` Miklos Szeredi
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=YnmK0VJhQ4sf8AMI@redhat.com \
--to=vgoyal@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=christian@brauner.io \
--cc=david@fromorbit.com \
--cc=dhowells@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=kzak@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=raven@themaw.net \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--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.