From owner-cvs-all Wed Feb 4 19:30:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA17808 for cvs-all-outgoing; Wed, 4 Feb 1998 19:30:59 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA17785 for ; Wed, 4 Feb 1998 19:30:49 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id DAA04698; Thu, 5 Feb 1998 03:30:47 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id EAA01371; Thu, 5 Feb 1998 04:30:47 +0100 (MET) Message-ID: <19980205043046.34988@follo.net> Date: Thu, 5 Feb 1998 04:30:46 +0100 From: Eivind Eklund To: Garrett Wollman Cc: Eivind Eklund , cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf options src/sys/gnu/ext2fs ext2_alloc.c ext2_balloc.c ext2_inode.c ext2_lookup.c ext2_subr.c ext2_vnops.c src/sys/i386/i386 busdma_machdep.c machdep.c pmap.c swtch.s trap.c vm86.c vm_machdep.c src/sys/i386/ibcs2 ibcs2_sysi86. References: <199802042234.OAA23694@freefall.freebsd.org> <199802050239.VAA19082@khavrinen.lcs.mit.edu> <19980205035631.28915@follo.net> <199802050306.WAA19161@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <199802050306.WAA19161@khavrinen.lcs.mit.edu>; from Garrett Wollman on Wed, Feb 04, 1998 at 10:06:15PM -0500 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe cvs-all" On Wed, Feb 04, 1998 at 10:06:15PM -0500, Garrett Wollman wrote: > < said: > > > However, there are some uses of DIAGNOSTIC (e.g, in vm_zone.h) that require > > it to be enabled for corresponding C-files to get support routines. This > > implies that at least some people use it as a global option. Perhaps the > > correct thing to do would be to split the option? > > Well, the way I've always used it was to turn it on for just those > specific modules I was debugging. That keeps the code perturbation > down to a minimum. I think it's a safe bet that anybody who really > needs to use this option knows what he is doing and can deal with the > necessary choices involved. I thought this was what DEBUG was for, except that it has been abused a lot of places? I've always consider the options as DEBUG - something is/might be wrong in my code. Do everything possible to find it, including spewing tons of debug info everywhere. DIAGNOSTIC - Something is wrong with the system. Check invariants etc, and spew info in those places where something fairly significant/dangerous happens. Users can be asked to run this to let a developer find out what is actually happening to their system. I've also always wanted an extra option INVARIANT - Check data structure invariants at all possible points, to be certain kernel panic()s as soon as something is wrong. Will slow system down _significantly_. to take over some of the functionality of DIAGNOSTIC, and do everything that is computerly possibly to see inconsistencies early, and thus make diagnosing easier. I can back out the diagnostic change and split it into a new-style 'options INVARIANT' and an old-style 'print debug-info'? It might be an idea for the invariants to be enabled whenever DIAGNOSTIC is enabled, or perhaps a third old-style option that can be used for this (to avoid enabling invariant-checks that propagate whenever somebody use DIAGNOSTIC to get debug-messages). Or whatever. We just need to find out what to do :-) Eivind.