deischen at freebsd.org
Mon Mar 30 12:50:10 PDT 2009
On Mon, 30 Mar 2009, Tim Kientzle wrote:
> Poul-Henning Kamp wrote:
>> In message <8321954E-5CFF-45F9-9F87-BE83659E4C8D at mac.com>, Marcel Moolenaar
>>> With so many drivers returning ENXIO whenever something (i.e
>>> anything) is wrong, how meaningful is ENXIO in diagnosing
>>> 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.
Just add the other error values in the upper half of the
word, and have __errno() return with the upper half
masked out. VxWorks doesn't something similar with
their errno, the lower half is the error and they
use the upper half to identify the module from which
More information about the freebsd-arch