[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1811033.1582289832@warthog.procyon.org.uk>
Date: Fri, 21 Feb 2020 12:57:12 +0000
From: David Howells <dhowells@...hat.com>
To: Stefan Metzmacher <metze@...ba.org>
Cc: dhowells@...hat.com, viro@...iv.linux.org.uk, raven@...maw.net,
mszeredi@...hat.com, christian@...uner.io,
linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/19] VFS: Filesystem information and notifications [ver #16]
Stefan Metzmacher <metze@...ba.org> wrote:
> > 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_ flags
> supported in openat2?
If that's the rule, then fine. I presume these are a replacement for AT_*.
But the set of RESOLVE_* flags does not appear to be complete - and why's it
not in linux/fs.h if it's meant to be used by everything?
Anyway, it lacks a RESOLVE_NO_AUTOMOUNT flag. This is not quite the same as
the documented behaviour of RESOLVE_NO_XDEV.
> > len = fsinfo(AT_FDCWD, "/afs/grand.central.org/doc", ¶ms,
> > &address, sizeof(address));
>
> Also passing sizeof(params) would allow future updates of fsinfo_params,
> also similar to openat2(), clone3()...
I can put that at the beginning of the params block or put dirfd in there. If
I remember rightly, 6-arg syscalls are discouraged because they may need
special handling on some arches.
David
Powered by blists - more mailing lists