On Mon, Apr 27, 2026 at 08:17:43PM +0600, Dorjoy Chowdhury wrote: > On Mon, Apr 27, 2026 at 7:28 PM Florian Weimer <[email protected]> wrote: > > > > * Dorjoy Chowdhury: > > > > > diff --git a/include/uapi/asm-generic/errno.h > > > b/include/uapi/asm-generic/errno.h > > > index 92e7ae493ee3..bd78e69e0a43 100644 > > > --- a/include/uapi/asm-generic/errno.h > > > +++ b/include/uapi/asm-generic/errno.h > > > @@ -122,4 +122,6 @@ > > > > > > #define EHWPOISON 133 /* Memory page has hardware error */ > > > > > > +#define EFTYPE 134 /* Wrong file type for the intended > > > operation */ > > > + > > > #endif > > > > This is what POSIX says about EFTYPE, in the Rationale for System > > Interfaces: > > > > “ > > [EFTYPE] > > This error code was proposed in earlier proposals as "Inappropriate > > operation for file type", meaning that the operation requested is > > not appropriate for the file specified in the function call. This > > code was proposed, although the same idea was covered by [ENOTTY], > > because the connotations of the name would be misleading. It was > > pointed out that the fcntl() function uses the error code [EINVAL] > > for this notion, and hence all instances of [EFTYPE] were changed to > > this code. > > ” > > > > So I'm not sure if reusing this name is a good idea. > > > > Thanks for pointing this out. I had started out the patch series with > ENOTREGULAR and it was discussed that EFTYPE was a better and more > generic error code which is also used in BSD systems like FreeBSD[1] > and MacOS[2]. I also agree that EFTYPE makes sense. We can of course > change to something else if everyone agrees. > > cc Christian Brauner who originally suggested EFTYPE for input on this. > > [1]: https://man.freebsd.org/cgi/man.cgi?errno(2) > [2]: https://developer.apple.com/documentation/foundation/posixerror/eftype
Given that both the bsds and macos already use that is there a good reason to return ENOTTY for this other than a standard we ignore most of the time anyway? I'm honestly asking.
