Re: [9fans] [RFD] Standardizing core error strings

["Ronald G. Minnich" <rminnich@lanl.gov>]

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