This patch shifts the key-related error codes up by one and inserts an
ECANCELED error code where not already defined. It seems that has been defined
in glibc without passing it back to the kernel:-/
Who arbitrates error number allocations anyway?
Signed-Off-By: David Howells <[email protected]>
---
warthog>diffstat errno-269bk5.diff
asm-alpha/errno.h | 9 +++++----
asm-generic/errno.h | 9 +++++----
asm-sparc/errno.h | 9 +++++----
asm-sparc64/errno.h | 9 +++++----
4 files changed, 20 insertions(+), 16 deletions(-)
On Gwe, 2004-10-22 at 17:57, David Howells wrote:
> This patch shifts the key-related error codes up by one and inserts an
> ECANCELED error code where not already defined. It seems that has been defined
> in glibc without passing it back to the kernel:-/
>
> Who arbitrates error number allocations anyway?
Generally nobody because new error codes are almost always a mistake in
the first place especially when they don't appear in standards so no
application will correctly or sanely handle them.
You should use existing codes IMHO. Lets see
EKEYEXPIRED - ETIME (ETIMEDOUT ? ENOLINK ?)
ENOKEY - ENOENT
EKEYREJECTED - EILSEQ / EMSGSIZE / EPROTOTYPE ..
EKEYREVOKED - EREMCHG / ESHUTDOWN
And now I can use your key stuff with an existing C library and in LSB
compliant or cross platform code and give more information. If you look
through the kernel history we've almost never ever added an error code,
adding them just causes compatibility pain for everyone
Alan
On Fri, Oct 22, 2004 at 05:57:42PM +0100, David Howells wrote:
>
> This patch shifts the key-related error codes up by one and inserts an
> ECANCELED error code where not already defined. It seems that has been defined
> in glibc without passing it back to the kernel:-/
Not sure what's the story behind ECANCELED not being in kernel headers,
certainly it is something only userland needs ATM.
It is a POSIX mandated errno code used in aio_* that glibc is using
since 1998, so it would be really bad to break all apps using aio.
The values you posted match exactly what glibc is using:
libc/sysdeps/unix/sysv/sysv4/solaris2/bits/errno.h:# define ECANCELED 47 /* Operation canceled. */
libc/sysdeps/unix/sysv/aix/bits/errno.h:# define ECANCELED 117 /* Asynchronous i/o cancelled. */
libc/sysdeps/unix/sysv/linux/alpha/bits/errno.h:# define ECANCELED 131
libc/sysdeps/unix/sysv/linux/sparc/bits/errno.h:# define ECANCELED 127
libc/sysdeps/unix/sysv/linux/bits/errno.h:# define ECANCELED 125
libc/sysdeps/unix/sysv/linux/hppa/bits/errno.h:# define ECANCELED ECANCELLED
libc/sysdeps/mach/hurd/bits/errno.h:#define ECANCELED _HURD_ERRNO (118)/* Operation canceled */
just maybe asm-parisc/errno.h could have
#define ECANCELED ECANCELLED
added (ECANCELED is the POSIX mandated spelling, while asm-parisc/errno.h
for some reason defines ECANCELLED).
Jakub
> You should use existing codes IMHO. Lets see
>
> EKEYEXPIRED - ETIME (ETIMEDOUT ? ENOLINK ?)
> ENOKEY - ENOENT
> EKEYREJECTED - EILSEQ / EMSGSIZE / EPROTOTYPE ..
> EKEYREVOKED - EREMCHG / ESHUTDOWN
The problem with doing that is that these error codes have specific meanings
that we're then violating the standards by overloading. Take open() for
example: it's possible that this will return ENOENT because there's no file
there to be opened; I think it's a bad idea for it to return ENOENT when there
is a file there, but we don't have a key, hence ENOKEY.
David
On Mon, 2004-10-25 at 10:31 +0100, David Howells wrote:
> Take open() for
> example: it's possible that this will return ENOENT because there's no file
> there to be opened; I think it's a bad idea for it to return ENOENT when there
> is a file there, but we don't have a key, hence ENOKEY.
take open....
you don't have access to the file because you don't have a matching key
to get to it. Doesn't that kinda say EACCESS (or EPERM) would be a/the
proper return code ?
--