linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
	Miklos Szeredi <mszeredi@redhat.com>,
	linux-fsdevel@vger.kernel.org, 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>,
	Karel Zak <kzak@redhat.com>, 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>,
	Amir Goldstein <amir73il@gmail.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [RFC PATCH] getvalues(2) prototype
Date: Wed, 23 Mar 2022 16:23:34 +0100	[thread overview]
Message-ID: <CAJfpegsBmed6dchjgVeQ-OPGYBiU+2GPgsoJegjuPTrcLs6-8g@mail.gmail.com> (raw)
In-Reply-To: <Yjsiv2XesJRzoeTW@kroah.com>

On Wed, 23 Mar 2022 at 14:38, Greg KH <gregkh@linuxfoundation.org> wrote:

> This has been proposed in the past a few times.  Most recently by the
> KVM developers, which tried to create a "generic" api, but ended up just
> making something to work for KVM as they got tired of people ignoring
> their more intrusive patch sets.  See virt/kvm/binary_stats.c for what
> they ended up with, and perhaps you can just use that same type of
> interface here as well?

So this looks like a fixed set of statistics where each one has a
descriptor (a name, size, offset, flags, ...) that tells about the
piece of data to be exported.  The stats are kept up to date in kernel
memory and copied to userspace on read.  The copy can be selective,
since the read can specify the offset and size of data it would like
to retrieve.

The interface is self descriptive and selective, but its structure is
fixed for a specific object type, there's no way this could be
extended to look up things like extended attributes.  Maybe that's not
a problem, but the lack of a hierarchical namespace could turn out to
be a major drawback.

I think people underestimate the usefulness of hierarchical
namespaces, even though we use them extensively in lots of well
established interfaces.

Thanks,
Miklos

  reply	other threads:[~2022-03-23 15:23 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 19:27 [RFC PATCH] getvalues(2) prototype Miklos Szeredi
2022-03-22 19:30 ` Miklos Szeredi
2022-03-22 20:36 ` Casey Schaufler
2022-03-22 20:53   ` Casey Schaufler
2022-03-23  7:14   ` Greg KH
2022-03-23  7:16 ` Greg KH
2022-03-23 10:26   ` Bernd Schubert
2022-03-23 11:42     ` Greg KH
2022-03-23 12:06       ` Bernd Schubert
2022-03-23 12:13         ` Greg KH
2022-03-23 19:29     ` J. Bruce Fields
2022-03-23 11:42 ` Christian Brauner
2022-03-23 13:24   ` Miklos Szeredi
2022-03-23 13:38     ` Greg KH
2022-03-23 15:23       ` Miklos Szeredi [this message]
2022-03-24  6:56         ` Greg KH
2022-03-23 13:51     ` Casey Schaufler
2022-03-23 14:00       ` Miklos Szeredi
2022-03-23 22:39         ` Casey Schaufler
2022-03-23 22:19     ` Theodore Ts'o
2022-03-24  6:34       ` Christoph Hellwig
2022-03-24  8:44       ` Miklos Szeredi
2022-03-24 16:15         ` Eric W. Biederman
2022-03-25  8:46         ` Karel Zak
2022-03-25  8:54           ` Greg KH
2022-03-25  9:25             ` Karel Zak
2022-03-26  4:19               ` Theodore Ts'o
2022-03-25 18:40           ` Linus Torvalds
2022-03-25 11:02         ` Cyril Hrubis
2022-03-23 22:58 ` Dave Chinner
2022-03-23 23:17   ` Casey Schaufler
2022-03-24  8:57   ` Miklos Szeredi
2022-03-24 10:34     ` Amir Goldstein
2022-03-24 20:31     ` Dave Chinner
2022-03-25  9:10       ` Karel Zak
2022-03-25 16:42       ` Trond Myklebust
2022-03-27 21:03         ` Dave Chinner

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=CAJfpegsBmed6dchjgVeQ-OPGYBiU+2GPgsoJegjuPTrcLs6-8g@mail.gmail.com \
    --to=miklos@szeredi.hu \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=christian@brauner.io \
    --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=mszeredi@redhat.com \
    --cc=raven@themaw.net \
    --cc=torvalds@linux-foundation.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 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).