[MiNT] New error codes in kernel

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Hi,

as mentioned in another thread, the new kernel uses new error codes.  This
may lead to some problems that should be explained.

With new kernels (we have only started, the migration is not finished
yet) you will often see "unknown error" if your software does not know
about an error code that is returned by the new kernel.

If you are not a programmer you will probably not want to read the rest of
this mail ...

Why has this been changed?  An average Unix system does know a lot more
error codes than traditional GEMDOS.  Kay Roemer has introduced new error
codes for MiNTNet ("Network unreachable", "No route to host", ...), MiNT
has introduced a few ones ("Operation would block"), and Magic has
invented some jokes ("Terminated with bombs", "Aborted by user").

But most of the commonly used error codes were missing until today.  Both
the MiNTLib and the kernel tried to work around the problems caused by
this restriction by melting several error codes into one.  The most
significant examples were:

- ENOSYS, EINVAL
  ENOSYS ("Function not implemented") and EINVAL ("Invalid argument") used
  to be the same.  This was a bad idea because they describe different
  things.  ENOSYS means "the operating system does not know about this
  function" and EINVAL means "this function is known but you cannot use
  that particular argument here".  Example: Plain TOS should return ENOSYS
  when Fcntl() is called (because TOS does not know this call) but
  MiNT should return EINVAL if the underlying device does not support 
  the particular opcode that Fcntl() has been called with.  Another
  example would be Ssystem().

- EPERM, EACCES
  Again two things that were described the same.  EPERM means "Operation 
  not permitted" (e. g. a lemming user may not change the system date)
  whereas EACCES ("Permission denied" but "Access denied" would be better)
  means that you don't have sufficient rights to access a particular
  resource.  Usually you don't have read/write/execute permissions for
  a file or directory.

- ENOENT, ESRCH, ECHILD, EISDIR
  ENOENT: No such file or directory
  ESRCH: No such process
  ECHILD: No child processes
  EISDIR: Is a directory
  It's pretty obvious that this used to be somewhat the fallback error
  code.

As mentioned above: The concept has not been consequently realized in the
new kernel, mainly because it seems to be a better idea to change
"critical" things step by step so that it is easier to revert changes
which lead to unsolvable problems (my first "radical" approach ended in
desaster...).  The biggest missing piece are the error codes produced by
file system operations: ENOENT, EISDIR, ENOTEMPTY, EEXIST, EACCES,
ENOTDIR, ...  These will require a lot of changes which are potentially
dangerous.

These restrictions of MiNT/GEMDOS have often lead to problems when porting
software because programs often relied on a particular error code being
returned by the operating system.  In most cases these bugs are very hard
to find because they will produce run-time errors and not compile-time
errors.  Furthermore the error messages are often irritating:

	$ rmdir /tmp
	bash: /tmp: File exists (really "Directory is not empty")
	$ make
	^C
	make: ***: file not found (really "No child processes")
	$ kill 99999
	kill: 99999: file not found (really "No such process")

OK, in the next couple of months you will often see "unknown error"
(programs linked against a very new MiNTLib will at least report "unknown
error 123") but later we will all hopefully benefit from more descriptive
error messages and less effort for porting software.

We have tried our best to remain as compatible as possible to GEMDOS but
of course we cannot guarantee everything is 100 % flawless.  For details
on the new error codes you should have a look at src/include/errno.h in
the latest kernel sources or /usr/include/mint/errno.h in the next
MiNTLib.  BTW, from now on "errno.h" gets shared between the kernel and
the MiNTLib, they are identical.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000/
mailto:gufl0000@stud.uni-sb.de