[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20200305152339.3uitms2pua5wzzed@wittgenstein>
Date: Thu, 5 Mar 2020 16:23:39 +0100
From: Christian Brauner <christian.brauner@...ntu.com>
To: Aleksa Sarai <cyphar@...har.com>
Cc: Florian Weimer <fweimer@...hat.com>,
David Howells <dhowells@...hat.com>, linux-api@...r.kernel.org,
viro@...iv.linux.org.uk, metze@...ba.org,
torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: Have RESOLVE_* flags superseded AT_* flags for new syscalls?
On Fri, Mar 06, 2020 at 01:11:54AM +1100, Aleksa Sarai wrote:
> On 2020-03-02, Florian Weimer <fweimer@...hat.com> 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.
>
> There is one being proposed at the moment as part of the compressed
> read/write work[1].
That work predates openat2() having been merged so there's an argument
to be made that it should be on top of openat2() imho. But that assumes
people agree with
https://lore.kernel.org/linux-fsdevel/3607683.1583419401@warthog.procyon.org.uk/T/#m58c1b6c2697e72e7b42bdbea248178ed31b7d787
and I haven't heard anything in either direction...
Christian
Powered by blists - more mailing lists