Date: Mon, 30 Mar 2009 11:55:53 -0700 From: Tim Kientzle <kientzle@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: FreeBSD Arch <arch@freebsd.org>, Marcel Moolenaar <xcllnt@mac.com> Subject: Re: On errno Message-ID: <49D115B9.7030501@freebsd.org> In-Reply-To: <93378.1238438607@critter.freebsd.dk> References: <93378.1238438607@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49D115B9.7030501>