[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200331092101.fnipaxqewol2hzd2@ws.net.home>
Date: Tue, 31 Mar 2020 11:21:01 +0200
From: Karel Zak <kzak@...hat.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: David Howells <dhowells@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@...iv.linux.org.uk>, dray@...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,
Christian Brauner <christian.brauner@...ntu.com>,
keyrings@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: Upcoming: Notifications, FS notifications and fsinfo()
On Mon, Mar 30, 2020 at 10:28:56PM +0200, Miklos Szeredi wrote:
> All this could be solved with a string key/value representation of the
> same data, with minimal performance loss on encoding/parsing. The
> proposed fs interface[1] is one example of that, but I could also
> imagine a syscall based one too.
Yes, key/value is possible solution. The question is if we really
need to add extra /sys-like filesystem to get key/value ;-) I can
imagine key/value from FD based interface without open/read/close for
each attribute,
fd = open("/mnt", O_PATH);
fsinfo(fd, "propagation", buf, sizeof(buf));
fsinfo(fd, "fstype", buf, sizeof(buf));
close(fd);
why I need /mountfs/<id>/propagation and /mountfs/<id>/fstype to get
the same? It sounds like over-engineering without any extra bonus.
Anyway, if we have FD based interfaces like fsopen(), fsmount(),
open_tree() and move_mount() then it sounds strange that you cannot
use the FD to ask kernel for the mount node attributes and you need
to open and read another /sys-like files.
IMHO it would be nice that after open(/mnt, O_PATH) I can do whatever
with the mount point (umount, move, reconfigure, query, etc.). Please,
try to keep it simple and consistent ;-)
Karel
--
Karel Zak <kzak@...hat.com>
http://karelzak.blogspot.com
Powered by blists - more mailing lists