cvs commit: src/sys/kern vfs_mount.c

[Ceri Davies]

On Wed, Nov 09, 2005 at 08:35:16AM -0800, Frank Mayhar wrote:
> 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.

It would be instructive for someone to look at the OpenSolaris code base,
find out how they have done this and then describe it to us (in a
clean-room kind of abstration).  From the marketing and user
perspective, real language error messages really do get pulled through
each layer of the kernel into userland.

Ceri
-- 
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.			  -- Einstein (attrib.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20051109/00ef69cb/attachment.bin