cvs commit: src/sys/kern vfs_mount.c
ceri at submonkey.net
Wed Nov 9 16:43:43 GMT 2005
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
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.
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
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20051109/00ef69cb/attachment.bin
More information about the cvs-src