From owner-freebsd-current Tue Dec 9 19:37:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08462 for current-outgoing; Tue, 9 Dec 1997 19:37:05 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08451 for ; Tue, 9 Dec 1997 19:36:52 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id UAA14744; Tue, 9 Dec 1997 20:51:55 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd014671; Tue Dec 9 20:51:42 1997 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id UAA06192; Tue, 9 Dec 1997 20:36:05 -0700 (MST) From: Terry Lambert Message-Id: <199712100336.UAA06192@usr06.primenet.com> Subject: Re: VM system info To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Wed, 10 Dec 1997 03:36:05 +0000 (GMT) Cc: perhaps@yes.no, freebsd-current@freebsd.org In-Reply-To: <199712091643.LAA04851@crh.cl.msu.edu> from "Charles Henrich" at Dec 9, 97 11:43:31 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >(5) Code prerequisites is documented through assert() or similar > > functionality. > > Egads! I wish assert() was thrown down to the pits of hell. Its a > programmers cop out. In almost no circumstance does one ever need to assert. > If you find an error condition, COPE as best you can! Especially in the > kernel. The function of an assert() is not to live in production code. The function of assert() is to provide developers with feedback about improper use of function interfaces. This lets functions document expectations on the way in, and, if you correctly implement single-entry/single-exit like you should, on the way out as well. A good example would be functions with locking side-effects. Like those involved in causeing the "free vnode isn't" bug we are all so fond of, but for which the code is a sacred cow and so it's never been fixed. Knowing that a lock that was supposed to be held is not held as expected, or is held when it is not expected to be held, in combination with a branch-patch validation to exercise all code paths can result in early and easy identification and correction of bugs. Right now, there is an obvious error in VOP_LOCK()'s interaction with vclean() and associated functions (for example), resulting in the "free vnode isn't" bug described above. This is only going to get worse in the SMP kernel, and in the UP kernel, assuming we allow for kernel preemption for use in supporting things like kernel threads and kernel processes. So it's not an SMP only problem. Topologically, other than the names for the primitives, Kernel preemption for RT support is equivalent to kernel preemption for kernel threading support is equivalent to kernel reeentrancy for SMP. I can't see SMP progressing to discrete locking with any reasonable guarantess against deadlock or inversion bugs without this type of assurance. In production code, and assert becomes a comment, and is not even compiled into the code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.