[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200302125531.7z2viveb3zxhqkuj@wittgenstein>
Date: Mon, 2 Mar 2020 13:55:31 +0100
From: Christian Brauner <christian.brauner@...ntu.com>
To: Florian Weimer <fweimer@...hat.com>
Cc: David Howells <dhowells@...hat.com>, linux-api@...r.kernel.org,
viro@...iv.linux.org.uk, metze@...ba.org,
torvalds@...ux-foundation.org, cyphar@...har.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Have RESOLVE_* flags superseded AT_* flags for new syscalls?
On Mon, Mar 02, 2020 at 01:42:50PM +0100, Florian Weimer wrote:
> * Christian Brauner:
>
> > One difference to openat() is that openat2() doesn't silently ignore
> > unknown flags. But I'm not sure that would matter for iplementing
> > openat() via openat2() since there are no flags that openat() knows about
> > that openat2() doesn't know about afaict. So the only risks would be
> > programs that accidently have a bit set that isn't used yet.
>
> Will there be any new flags for openat in the future? If not, we can
> just use a constant mask in an openat2-based implementation of openat.
>From past experiences with other syscalls I would expect that any new
features would only be available through openat2().
The way I see it in general is that a revised version of a syscall
basically deprecates the old syscall _wrt to new features_, i.e. new
features will only be available through the revised version unless there
are very strong reasons to also allow it in the old version (security
bug or whatever).
(But I don't want to be presumptuous here and pretend I can make any
definiteve statement. Ultimately it's up to the community, I guess. :))
Christian
Powered by blists - more mailing lists