Re: [PATCH 00/19] VFS: Filesystem information and notifications [ver #16]

From: Stefan Metzmacher <metze@samba.org>
To: David Howells <dhowells@redhat.com>, viro@zeniv.linux.org.uk
Cc: raven@themaw.net, mszeredi@redhat.com, christian@brauner.io,
	linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/19] VFS: Filesystem information and notifications [ver #16]
Date: Wed, 19 Feb 2020 11:23:54 +0100	[thread overview]
Message-ID: <ba89cc20-ac0c-cf13-9953-5d5546aab6de@samba.org> (raw)
In-Reply-To: <158204549488.3299825.3783690177353088425.stgit@warthog.procyon.org.uk>

[-- Attachment #1.1: Type: text/plain, Size: 1608 bytes --]

Hi David,

I have a few generic remarks for new syscalls...

>  (3) New single-bit capability flags can be added.  This is a structure-typed
>      attribute and, as such, (2) applies.  Any bits you wanted but the kernel
>      doesn't support are automatically set to 0.
> 
> fsinfo() may be called like the following, for example:
> 
> 	struct fsinfo_params params = {
> 		.at_flags	= AT_SYMLINK_NOFOLLOW,

Shouldn't all new syscalls be able to provide the RESOLVE_

Shouldn't all new syscalls be able to provide the RESOLVE_ flags
supported in openat2?

> 		.flags		= FSINFO_FLAGS_QUERY_PATH,
> 		.request	= FSINFO_ATTR_AFS_SERVER_ADDRESSES,
> 		.Nth		= 2,
> 	};
> 	struct fsinfo_server_address address;
> 	len = fsinfo(AT_FDCWD, "/afs/grand.central.org/doc", &params,
> 		     &address, sizeof(address));

Also passing sizeof(params) would allow future updates of fsinfo_params,
also similar to openat2(), clone3()...

> ========================
> FILESYSTEM NOTIFICATIONS
> ========================
> 
> The second system call, watch_mount(), places a watch on a point in the
> mount topology specified by the dirfd, path and at_flags parameters.  All
> mount topology change and mount attribute change notifications in the
> subtree rooted at that point can be intercepted by the watch.  Watches are
> ducted through pipes:
> 
> 	int fd[2];
> 	pipe2(fd, O_NOTIFICATION_PIPE);
> 	ioctl(fd[0], IOC_WATCH_QUEUE_SET_SIZE, BUF_SIZE);
> 	watch_mount(AT_FDCWD, "/", 0, fd[0], 0x02);

I guess similar things apply here.

Does that make sense to you?

metze

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]