From owner-freebsd-arch@FreeBSD.ORG Wed Apr 1 16:13:54 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 99DFD106564A for ; Wed, 1 Apr 2009 16:13:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 876138FC18 for ; Wed, 1 Apr 2009 16:13:54 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from jflores-gxdt755.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KHF002NJJQGXN30@asmtp015.mac.com> for arch@freebsd.org; Wed, 01 Apr 2009 09:13:54 -0700 (PDT) Message-id: From: Marcel Moolenaar To: FreeBSD Arch In-reply-to: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com> Date: Wed, 01 Apr 2009 09:13:28 -0700 References: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com> X-Mailer: Apple Mail (2.930.3) Cc: 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: Wed, 01 Apr 2009 16:13:54 -0000 On Mar 30, 2009, at 10:31 AM, Marcel Moolenaar wrote: > This begs the question: what is stopping us from adding new > error codes? >> kientzle@ wrote: >> 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. I agree that well-known system calls should not be changed willy-nilly. But what about error codes returned from GEOM or other FreeBSD-specific subsystems? >> phk@ wrote: > >> 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). Strings are not to be used to relay error conditions between kernel and processes. Interpretation of the string is unnecessarily hard (if not impossible) if the process wants to take corrective action. They're not even good for printing, because the process is not left in control over its own output (i18n has been mentioned). >> kientzle@ responded: >> This is the right direction: Basically, add a new variable >> that augments errno instead of extending the possible values of >> errno. Augmentation seems logical. Does anyone know if this has been done in some OS already? >> phk@ wrote: >> Don't overengineer it guys. I agree that over engineering is not a good thing, but under- engineering is worse. Handwaving real-world demands/requirements with nothing more than emotional responses that lack technical argumentation does not build the "damn best OS". Oh, and yes: I have been thinking about localization of the kernel. While I don't see this to be urgent or critical to FreeBSD itself, I can see a "market" for it. >> wollman@ wrote: >> But all this is really irrelevant if no other operating system or >> standard adopts the interface. Interfaces which are peculiar to >> FreeBSD are rarely useful. That's a very good point indeed. -- Marcel Moolenaar xcllnt@mac.com