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 Regards, Dorjoy
