Re: [RFC PATCH v5 1/2] vfs: add O_CREAT|O_DIRECTORY to open*(2)

[Christian Brauner]

On Thu, May 28, 2026 at 08:17:31AM +1000, NeilBrown wrote:
> On Wed, 27 May 2026, Christian Brauner wrote:
> > > 
> > > I'm not convinced the change to EOPNOTSUPP is a good idea.  It should
> > > be a separate patch so that it can be reviewed separately.
> > > 
> > > EOPNOTSUPP is documented as
> > >        EOPNOTSUPP      Operation not supported on socket (POSIX.1-2001).
> > > 
> > > and we have no sockets here!
> > 
> > Sorry, not even userspace tooling indicates that this has anything to do
> > with sockets.
> > 
> >     > which errno
> >     /usr/bin/errno
> > 
> >     > errno ENOTSUP
> >     ENOTSUP 95 Operation not supported
> >     
> >     > errno EOPNOTSUPP
> >     EOPNOTSUPP 95 Operation not supported
> 
> $ man 3 errno | grep EOPNOT
>      EOPNOTSUPP      Operation not supported on socket (POSIX.1-2001).
>                      (ENOTSUP and EOPNOTSUPP have the same value on Linux,  but

(ENOTSUP and EOPNOTSUPP have the same value on Linux, but according to POSIX.1 these error values should be distinct.)

Consistency be damned, I guess.

And if we start caring about POSIX again we should probably remove 90%
of our newer apis. It's irrelevant what the standard says. It matters
what we do in practice. Taking a tour through the kernel and trying to
prove that there's any 1:1 relationship between socket operations and
EOPNOTSUPP fails. Equally, going through large userspace projects to see
whether they treat EOPNOTSUPP as even vaguely socket related also fails.

Even glibc treats EOPNOTSUPP as the universal "not supported" sentinel
and raises it even independent of what the kernel returns. One example I
distincly remember is the fchmodat() AT_SYMLINK_NOFOLLOW userspace
emulation it had to do.

Maybe I really misunderstand the motivation for this discussion. But
this feels a bit like wasting time on something that we've already
established a while ago.