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

[NeilBrown]

On Thu, 28 May 2026, Christian Brauner wrote:
> 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.
> 

Maybe someone should update the man-page?

My main point was not that EOPNOTSUPP was a poor choice, but that an API
change needs to be managed properly (and I'm not sure it is worth it in
this case).

Thanks,
NeilBrown