From: Greg KH <gregkh@linuxfoundation.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Amir Goldstein <amir73il@gmail.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Dave Chinner <david@fromorbit.com>, Theodore Ts'o <tytso@mit.edu>,
Karel Zak <kzak@redhat.com>,
Christian Brauner <brauner@kernel.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: Tue, 3 May 2022 18:54:29 +0200 [thread overview]
Message-ID: <YnFeRe02RqclvZ87@kroah.com> (raw)
In-Reply-To: <CAJfpegtZjRca5QPm2QgPtPG0-BJ=15Vtd48OTnRnr5G7ggAtmA@mail.gmail.com>
On Tue, May 03, 2022 at 05:04:06PM +0200, Miklos Szeredi wrote:
> On Tue, 3 May 2022 at 16:53, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, May 03, 2022 at 05:39:46PM +0300, Amir Goldstein wrote:
>
> > > It should be noted that while this API mandates text keys,
> > > it does not mandate text values, so for example, sb iostats could be
> > > exported as text or as binary struct, or as individual text/binary records or
> > > all of the above.
> >
> > Ugh, no, that would be a total mess. Don't go exporting random binary
> > structs depending on the file, that's going to be completely
> > unmaintainable. As it is, this is going to be hard enough with random
> > text fields.
> >
> > As for this format, it needs to be required to be documented in
> > Documentation/ABI/ for each entry and key type so that we have a chance
> > of knowing what is going on and tracking how things are working and
> > validating stuff.
>
> My preference would be a single text value for each key.
Yes! That's the only sane way to maintain apis, and is why we do that
for sysfs.
If the key isn't present, there's no value, so userspace "knows" this
automatically and parsing this is trivial.
> Contents of ":mnt:info" contradicts that, but mountinfo has a long
> established, well documented format, and nothing prevents exporting
> individual attributes with separate names as well (the getvalues(2)
> patch did exactly that).
I understand, for "legacy" things like this, that's fine, but don't add
new fields or change them over time please, that way just gets us back
to the nightmare of preserving /proc/ file apis.
thanks,
greg k-h
next prev parent reply other threads:[~2022-05-03 16:54 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 [this message]
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
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=YnFeRe02RqclvZ87@kroah.com \
--to=gregkh@linuxfoundation.org \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).