cvs commit: src/sys/kern vfs_mount.c

[Frank Mayhar]

On Wed, 2005-11-09 at 08:01 +0100, Poul-Henning Kamp wrote:
> Modify perror(3), err(3) and similar to pull out the "extended"
> error, if there is one.

As a data point, the way this problem was solved in one particular
mainframe OS many years ago was with a more complex error code.  Errors
looked something like this:
	FMN-M0007-3 You shot yourself in the foot.
The "FMN" part indicate the part of the "kernel" (called the "monitor"
in those days) that issued the error, in this case the file management
naming subsystem, IIRC.  The "M" indicated that it was indeed a monitor
error.  The "0007" indicate the particular error itself, and the "3"
indicated the severity of the error.  Each module had its own set of
error messages and each error message could have up to seven
"severities," each corresponding to a more terse or more detailed
message.  The codes and messages themselves where defined in the source
itself using special comment types and were stuffed into a database by a
munger run at build time.  The error print routine looked up the code in
the database and printed the corresponding error message.

Now, I am by no means suggesting this as a solution.  I think it's
overkill for FreeBSD (hell, it was probably overkill for CP-6, but it
had its uses) but there is probably something to be learned from it
regardless.  Like, using a simple integer error code just doesn't quite
meet every need, and that there's no reason to have to "pull out" a
message from the kernel when 99% of the work can be done at build time,
with the runtime only needing to use a special, more complex error code
to get the job done.

In other words, I agree that the perror(3)/err(3) route in general
indicates the way to go, but a more general solution would obviously be
better.
-- 
Frank Mayhar frank at exit.com     http://www.exit.com/
Exit Consulting                 http://www.gpsclock.com/
                                http://www.exit.com/blog/frank/