[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegs3uDzFTE4PCjZ7aZsEh8b=iy_LqO1DBJoQzkP+i4aBmw@mail.gmail.com>
Date: Wed, 1 Apr 2020 17:33:57 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Lennart Poettering <mzxreary@...inter.de>
Cc: David Howells <dhowells@...hat.com>,
Christian Brauner <christian.brauner@...ntu.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>, dray@...hat.com,
Karel Zak <kzak@...hat.com>,
Miklos Szeredi <mszeredi@...hat.com>,
Steven Whitehouse <swhiteho@...hat.com>,
Jeff Layton <jlayton@...hat.com>, Ian Kent <raven@...maw.net>,
andres@...razel.de, keyrings@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Aleksa Sarai <cyphar@...har.com>
Subject: Re: Upcoming: Notifications, FS notifications and fsinfo()
On Wed, Apr 1, 2020 at 4:41 PM Lennart Poettering <mzxreary@...inter.de> wrote:
>
> On Di, 31.03.20 22:52, David Howells (dhowells@...hat.com) wrote:
>
> > Christian Brauner <christian.brauner@...ntu.com> wrote:
> >
> > > querying all properties of a mount atomically all-at-once,
> >
> > I don't actually offer that, per se.
> >
> > Having an atomic all-at-once query for a single mount is actually quite a
> > burden on the system. There's potentially a lot of state involved, much of
> > which you don't necessarily need.
>
> Hmm, do it like with statx() and specify a mask for the fields userspace
> wants? Then it would be as lightweight as it possibly could be?
Yes, however binary structures mixed with variable length fields are
not going to be pretty.
Again, if we want something even halfway sane for a syscall interface,
go with a string key/value vector.
If that's really needed. I've still not heard a convincing argument
in favor of a syscall.
Thanks,
Miklos
Powered by blists - more mailing lists