Kernel/Glibc: EOPNOTSUPP vs. ENOTSUP vs. ENOTSUPP (also [RFC] POSIX ACL kernel infrastructure)
Hello,
[This is a copy of a previous posting to linux-kernel.]
we have a bit of a mess concerning error definitions: POSIX 1003.1-200 defines the errors EOPNOTSUPP and ENOTSUP as follows:
[ENOTSUP] Not supported. The implementation does not support this feature of the Realtime Option Group.
[EOPNOTSUPP] Operation not supported on socket. The type of socket (address family or protocol) does not support the requested operation.
The standard further says the numbers assigned to ENOTSUP and EOPNOTSUPP
shall be unique.
Glibc seems to follow, but not quite:
[ENOTSUP] "Not supported". A function returns this error when certain parameter values are valid, but the functionality they request is not available. This can mean that the function does not implement a particular command or option value or flag bit at all. For functions that operate on some object given in a parameter, such as a file descriptor or a port, it might instead mean that only that specific object (file descriptor, port, etc.) is unable to support the other parameters given; different file descriptors might support different ranges of parameter values.
If the entire function is not available at all in the implementation, it returns ENOSYS instead.
[EOPNOTSUPP] "Operation not supported". The operation you requested is not supported. Some socket functions don't make sense for all types of sockets, and others may not be implemented for all communications protocols. In the GNU system, this error can happen for many calls when the object does not support the particular operation; it is a generic indication that the server knows nothing to do for that call.
In Glibc's sysdeps/unix/sysv/linux/bits/errno.h it says:
/* Linux has no ENOTSUP error code. */ # define ENOTSUP EOPNOTSUPP
In the kernel we define EOPNOTSUPP (architecture specific) and ENOTSUPP (in include/linux/errno.h). ENOTSUPP doesn't exist inside POSIX.
Is ENOTSUPP supposed to be the same as ENOTSUP? Some applications are already checking for ENOTSUP; if they are compiled against Glibs they currently will really check against EOPNOTSUPP. Renaming or aliasig ENOTSUPP to ENOTSUP will cause trouble, but aliasing ENOTSUP to EOPNOTSUPP leads to a conflict with POSIX.
What shall be done?
Regards,
Andreas.
------------------------------------------------------------------
Andreas Gruenbacher SuSE Linux AG
mailto:[email protected] Deutschherrnstr. 15-19
http://www.suse.de/ D-90429 Nuernberg, Germany
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------------------------------------------
Signature · 4 lines
------------------------------------------------------------------ Andreas Gruenbacher SuSE Linux AG mailto:[email protected] Deutschherrnstr. 15-19 http://www.suse.de/ D-90429 Nuernberg, Germany
Quoted 2 lines · Andreas Gruenbacher
The standard further says the numbers assigned to ENOTSUP and EOPNOTSUPP
shall be unique.
Where? I can't find it in my copy of 1003.1eD17
Followup to: <[email protected]> By author: Christoph Hellwig <[email protected]> In newsgroup: linux.dev.fs.devel
Quoted 7 lines · Andreas Gruenbacher
Quoted 2 lines
The standard further says the numbers assigned to ENOTSUP and EOPNOTSUPP
shall be unique.Where? I can't find it in my copy of 1003.1eD17
In the final version of 1003.1:2001, it is at the Base definitions volume, page 217, line 7687:
7686 The <errno.h> header shall provide a declaration for errno and
give positive values for the
7687 following symbolic constants. Their values shall be unique except
as noted below.
[ENOTSUP] and [EOPNOTSUPP] are both listed without allowing the numbers to be aliased.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 5 lines · Christoph Hellwig
Quoted 2 lines · Andreas Gruenbacher
The standard further says the numbers assigned to ENOTSUP and EOPNOTSUPP
shall be unique.Where? I can't find it in my copy of 1003.1eD17
That's in POSIX 1003.1-2001(Austin Group), not in 1003.1e draft 17.
--Andreas.