Date: Mon, 30 Mar 2009 15:33:48 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Tim Kientzle <kientzle@freebsd.org> Cc: FreeBSD Arch <arch@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Marcel Moolenaar <xcllnt@mac.com> Subject: Re: On errno Message-ID: <Pine.GSO.4.64.0903301529230.2318@sea.ntplx.net> In-Reply-To: <49D115B9.7030501@freebsd.org> References: <93378.1238438607@critter.freebsd.dk> <49D115B9.7030501@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Mar 2009, Tim Kientzle wrote: > Poul-Henning Kamp wrote: >> In message <8321954E-5CFF-45F9-9F87-BE83659E4C8D@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. 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 it came. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0903301529230.2318>