Date: Fri, 8 Nov 1996 19:01:05 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: David Greenman <dg@root.com> Cc: Terry Lambert <terry@lambert.org>, ponds!rivers@dg-rtp.dg.com, dyson@freefall.freebsd.org, freebsd-hackers@freefall.freebsd.org Subject: Re: More info on the daily panics... Message-ID: <Pine.SV4.3.95.961108173459.3290A-100000@parkplace.cet.co.jp> In-Reply-To: <199611080307.TAA04492@root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Nov 1996, David Greenman wrote:
> We've been down this road before. The asserts model isn't very well liked
> by a lot of people, including myself. It tends to bloat the sources with a
I think there were more ayes than nays on the list the last time we talked
about it.
> lot of unuseful checks and isn't flexible enough to accomodate more
> algorithmically complex checks.
Every #ifdef DIAGNOSTICS is an assert so we're already using them.
What I'm doing is classifying them and structuring them into the
functionality of both assertions and function specifications. This
enhances the debugging process both while writing the code and while
running the code.
I don't suggest that the model be used to replace things like the #ifdef
DDB stuff. The current structure is fine.
Writing code without parameter assertions basically communicates to the
consumer of the function that there is no policy regarding the use of the
function. It's hard to debug the fs when each fs author has a different
interpretation of how you use the exported functions.
The assertions would accelerate debugging because they would detect
problems early. A few consistency checks are not enough, by the time you
detect the problem the bug that triggered it is often too far away to back
track.
The best way to debug is to use gdb over a serial cable over a repeatable
bug. The best way for user environments that you don't have access to is
have them run the kernel with assertions turned on. It would be easier for
them to start debugging themselves because it would be very obvious what
the author of the function expected.
It will be possible for the brave to preprocess away both ASSUME and
REQUIRE assertions.
We could reach a level of quality nirvana where we can have the confidence
to run without a safety net using a *smaller*, *faster*, and *correct*
kernel.
The anal retentives could run with a DIAGNOSTIC kernel. Enabling both
ASSUME and REQUIRE assertions.
Look at the code below, I haven't added any more checking than before and
if it were the first time I looked at the code I would know a lot about
how to use it after reading just 2 lines into the code body.
Improved use of assertions:
ASSUMEs are only compiled into DIAGNOSTIC kernels, while REQUIREs are
compiled into the generic kernel. NDEBUG preprocesses away both.
==================================================================== void
vrele(vp)
register struct vnode *vp;
{
ASSUME(vp != NULL, "that vp isn't null");
REQUIRE(vp->v_usecount > 0, "that the ref count isn't already
zero");
vp->v_usecount--;
if ((vp->v_usecount == 1) &&
vp->v_object &&
(vp->v_object->flags & OBJ_VFS_REF)) {
vp->v_object->flags &= ~OBJ_VFS_REF;
vm_object_deallocate(vp->v_object);
return;
}
if (vp->v_usecount > 0)
return;
[ .. ]
Current
====================================================================
void
vrele(vp)
register struct vnode *vp;
{
#ifdef DIAGNOSTIC
if (vp == NULL)
panic("vrele: null vp");
#endif
vp->v_usecount--;
if ((vp->v_usecount == 1) &&
vp->v_object &&
(vp->v_object->flags & OBJ_VFS_REF)) {
vp->v_object->flags &= ~OBJ_VFS_REF;
vm_object_deallocate(vp->v_object);
return;
}
if (vp->v_usecount > 0)
return;
if (vp->v_usecount < 0) {
#ifdef DIAGNOSTIC
vprint("vrele: negative ref count", vp);
#endif
panic("vrele: negative reference cnt");
}
[ ... ]
Regards,
Mike Hancock
Are you going to "out-stubborn" me again?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.961108173459.3290A-100000>