On errno

[Tim Kientzle]

Poul-Henning Kamp wrote:
> In message <8321954E-5CFF-45F9-9F87-BE83659E4C8D at mac.com>, Marcel Moolenaar wri
> tes:
> 
>> With so many drivers returning ENXIO whenever something (i.e
>> anything) is wrong, how meaningful is ENXIO in diagnosing
>> problems?
>>
>> What do the various standards dictate or allow us to do?

POSIX does specify the range of allowable error codes
for a lot of system calls, but not all.  In my experience,
straying outside of that causes more problems than it's
worth.  A lot of programs make error-recovery decisions
based on errno values and that can get to be a portability
headache rather quickly (remember that for most software,
the default is going to be "if you don't recognize the errno
value, exit with a fatal error.")

> Long time ago, I proposed a scheme where a process can register
> a userland error-text buffer with the kernel.
> 
> Whenever a system call returns with error, the kernel has the
> opportunity to write an explanatory text in the registered
> buffer (if there is one).
> 
> That is not only backwards and standards compatible, but it is also
> much more expressive than errno.
> 
> If we start with teaching err(3) function about it, we even get
> a lot of coverage right away.

This is the right direction:  Basically, add a new variable
that augments errno instead of extending the possible values of
errno.  One variation, though:  I would argue for another
integer variable (errno_fine?) so that translations can be
done in userland (instead of having to deal with I18N in
the kernel) but the principle is still sound.

Tim