From owner-freebsd-arch@FreeBSD.ORG Mon Mar 30 19:50:06 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE6C410657DE; Mon, 30 Mar 2009 19:50:06 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6235F8FC12; Mon, 30 Mar 2009 19:50:06 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n2UJXmMi000876; Mon, 30 Mar 2009 15:33:48 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Mon, 30 Mar 2009 15:33:48 -0400 (EDT) Date: Mon, 30 Mar 2009 15:33:48 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Tim Kientzle In-Reply-To: <49D115B9.7030501@freebsd.org> Message-ID: References: <93378.1238438607@critter.freebsd.dk> <49D115B9.7030501@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Arch , Poul-Henning Kamp , Marcel Moolenaar Subject: Re: On errno X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 19:50:10 -0000 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