Re: [PATCH v3 09/14] vfs: add O_CREAT|O_DIRECTORY to open*(2)

[Jori Koolstra <jkoolstra@xs4all.nl>]

> Op 13-07-2026 11:54 CEST schreef Christoph Hellwig <hch@infradead.org>:
> 
>  
> On Tue, Jul 07, 2026 at 12:04:18PM +0200, Christian Brauner wrote:
> > I don't think any of this is really an argument worth considering.
> 
> It very much is.
> 
> > This is a lot of handwaving for the sake of portability and concerns
> > about past API mistakes. To both: so what. If an API is useful it's
> > useful, POSIX be damned. We're not going to be fenced in by some
> > standard.
> > 
> > 90% of our interfaces blow way past POSIX already - in most subsystems.
> > If we'd back down ever time someone shows up with "what about POSIX"
> > Linux would be irrelevant.
> 
> You can totaally ignore posix.  We need an interface that is self
> discoverable on Linux.  Any combination of flags that was accepted
> by previous kernels and gave different results than the new interface
> do not qualify for that.
> 
> > It's been years since O_DIRECTORY | O_CREAT has been made consistent
> > which means all LTS kernels have consistent behavior. We often make flag
> > combinations work that didn't work or where inconsisent before. Nothing
> > here is special at all.
> 
> No, we can't rely on something being backport to old enterprise/cloud
> kernel.  Doing so makes the interface unusable for actual applications.
> 

As far as I see it there are two types of UAPI change, one is almost never OK,
and one can be used sometimes. And O_CREAT|O_DIRECTORY falls into the second
category.

1. We have some UAPI that is used by user space and we wish to change its semantics.

2. We have some UAPI that is not used by user space and we wish to change its semantics.

In case 1 we force user space to update every use of the old UAPI if they
wish to be able to run their applications on a new kernel. This is unforgiving
and gave rise to the maxim "never change user space."

In the second case we don't require user space to do anything. The new feature
is opt-in, not opt-out. If the user space application wishes to use the new
feature they must either keep the fallback or update the minimally supported
kernel version. This is mostly fine.

We can detect which of the various behaviors of O_CREAT|O_DIRECTORY is active on
the running kernel, albeit somewhat an ugly test. And Pedro proved we are in
the second category UAPI change here, so we should just go ahead.

I am not opposed to using openat2(2) to have nicer feature detection, but it
should not halt this series imho.

Best,
Jori.