[9fans] [RFD] Standardizing core error strings

[9fans] [RFD] Standardizing core error strings

[Eric Van Hensbergen]

I'd really like to start an effort to standardize core error strings
for file servers - this core subset would be designed for use by core
error messages for u9fs, vacfs, fossil, and kfs -- but could be used
as the core subset for other application file servers.  Right now, the
error strings are scattered in various .c files -- for example from
u9fs.c:

char    Eauth[] =       "authentication failed";
char    Ebadfid[] =     "fid unknown or out of range";
char    Ebadoffset[] =  "bad offset in directory read";
char    Ebadusefid[] =  "bad use of fid";
char    Edirchange[] =  "wstat can't convert between files and directories";
 ...

The idea would be to create an error.h (or fs-error.h or whatever)
which combines these core definitions from the various file servers
and hopefully reduce any unnecessary duplication (and/or minor
differences in the strings).

A couple of my reasons for this:
a) it makes sense - duplication of error strings all over the source
code is silly
b) it'll help v9fs - we have to map error strings to Linux errno's,
and right now our mapping table is over 100 lines long

I'm NOT proposing we restrict file servers (or any other applications)
from having their own custom error messages as they see fit -- just
that they use the core error messages (from /sys/include/fs-error.h)
when applicable.

Inferno had something like this (os/port/error.h and emu/port/error.h)
-- probably be a good idea to try and come to some agreement with
those folks as well (adding them to cc: list)

       -eric

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

[Ronald G. Minnich]

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

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

[boyd, rounin]

> Sorry, I'm just back from DC and tired, so this probably makes no sense.

trouble is that errstrs (in english) don't internationalise and E* is too vague.

--
MGRS 31U DQ 52572 12604