From owner-freebsd-arch@FreeBSD.ORG Mon Mar 30 19:13:52 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 C7376106564A for ; Mon, 30 Mar 2009 19:13:52 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 86AAB8FC17 for ; Mon, 30 Mar 2009 19:13:52 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n2UIts3b091715; Mon, 30 Mar 2009 11:55:54 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id ru482dr4ndgt8n5gyfgtiyv3ii; Mon, 30 Mar 2009 11:55:54 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <49D115B9.7030501@freebsd.org> Date: Mon, 30 Mar 2009 11:55:53 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.19) Gecko/20090226 SeaMonkey/1.1.14 MIME-Version: 1.0 To: Poul-Henning Kamp References: <93378.1238438607@critter.freebsd.dk> In-Reply-To: <93378.1238438607@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Arch , Marcel Moolenaar Subject: Re: On errno X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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:13:53 -0000 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