From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 10 Jun 2005 21:10:52 -0600 From: "Ronald G. Minnich" To: Eric Van Hensbergen , Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] [RFD] Standardizing core error strings In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: v9fs-developer@lists.sourceforge.net, inferno-list@vitanuova.com Topicbox-Message-UUID: 5e58a192-ead0-11e9-9d60-3106f5b1d025 I'd still prefer it if the errno could somehow be divided into two parts, one part for use by programs, the other by people. The reason is that I've found that the needs of the two diverge. For example, the Linux VFS layer really needs correct errno/errstr values for the vfs_create to work correctly. Standardization of the errno/errstr is very important at that point. I just fixed a simple problem in v9fs by adding another errstr message (a plan9ports variant) to the errstr->errno mapping table. For programs and Linux kernels that process errstr, variation is a bad thing. But, in a few cases, I've seen errstr values that are no better than Unix EINVAL -- "something went wrong somewhere" -- as people tried to use some standard Ewhatever from the set of kernel error messages. The Ewhatever doesn't quite fit -- and in a few cases is quite wrong -- but it seems people were trying to keep the set of possible error returns small. In errstr for people, variation is a good thing. To put it another way, errstr is for people and programs to read, and you hit some interesting problems in trying to serve two masters. Programs and kernels generally don't want lots of variation ("I don't care what went wrong, just that something went wrong") but people want to see variation ("Which of the 5 parameters was invalid, DAMMIT!"). Sorry, I'm just back from DC and tired, so this probably makes no sense. ron