From owner-freebsd-hackers Mon Feb 9 01:24:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA25500 for hackers-outgoing; Mon, 9 Feb 1998 01:24:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA25477; Mon, 9 Feb 1998 01:24:32 -0800 (PST) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id JAA02186; Mon, 9 Feb 1998 09:23:46 GMT Date: Mon, 9 Feb 1998 18:23:46 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Eivind Eklund cc: Eivind Eklund , FreeBSD Hackers Subject: Re: DIAGNOSTICS and DEBUG LOGGING (was Re: cvs commit: src/sys/conf options) In-Reply-To: <19980209091644.21614@follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 9 Feb 1998, Eivind Eklund wrote: > > > _ASSERTS - Enable precondition and other cheap assertions > > > _INVARIANTS - Enable invariant/postcondition checking (expensive) > > > INVARIANT_CODE - Compile in invariant functions. > > > > So we have 3 levels of "sanity checking" with increasing levels of cost. > > I like it, it's a good fit to how people want to use assertions in > > practice. > > Just to make this perfectly clear (I'm not certain if you got my > meaning or not): > > Enabling INVARIANT_CODE will not add _any_ checks to the kernel. > Instead, it will add the code that is necessary to enable any checks > at will. If INVARIANT_CODE is defined for the entire kernel, then > _ASSERTS or _INVARIANTS can be defined for any single file without any > compilation trouble, even if _ASSERTS/_INVARIANTS isn't enabled for > any other file. Ok. My initial brief glance at the code I saw it as a way to have light-weight invariants that didn't need a function to check the invariant. After thinking about it, although I could do this in the framework you describe there would probably be little value in doing so. So getting back to your definition, if we had a small subsystem/module that could be implemented in a single file we could have a static check_invariant() for the module within #ifdef _INVARIANTS. For larger subsystems/modules where the check_invariant() is invoked from many files we would use INVARIANT_CODE around the mysubsystem_check_invariant(). I guess this should be documented under man style. Mike > Eivind. > -- michaelh@cet.co.jp http://www.cet.co.jp CET Inc., Daiichi Kasuya BLDG 8F, 2-5-12 Higashi Shinbashi, Minato-ku, Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe hackers" in the body of the message