Date: Wed, 9 Nov 2005 16:43:34 +0000 From: Ceri Davies <ceri@submonkey.net> To: Frank Mayhar <frank@exit.com> Cc: Craig Rodrigues <rodrigc@freebsd.org>, src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/kern vfs_mount.c Message-ID: <20051109164333.GW94004@submonkey.net> In-Reply-To: <1131554116.98960.16.camel@realtime.exit.com> References: <26185.1131519693@critter.freebsd.dk> <1131554116.98960.16.camel@realtime.exit.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--iwjEIfU64POCkTAH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > 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. >=20 > 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 --=20 Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. -- Einstein (attrib.) --iwjEIfU64POCkTAH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDcic1ocfcwTS3JF8RAnruAJ9gUtPYmI72ss8q4IumoD6RCIlWMQCeNFBH ofYlsMDn0Lw0V536Q/hfBaI= =LKhf -----END PGP SIGNATURE----- --iwjEIfU64POCkTAH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051109164333.GW94004>