From owner-freebsd-current Wed Mar 10 11: 0:24 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1896D1537A for ; Wed, 10 Mar 1999 11:00:20 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA57042; Wed, 10 Mar 1999 10:59:55 -0800 (PST) (envelope-from dillon) Date: Wed, 10 Mar 1999 10:59:55 -0800 (PST) From: Matthew Dillon Message-Id: <199903101859.KAA57042@apollo.backplane.com> To: Garrett Wollman Cc: Dan Swartzendruber , freebsd-current@FreeBSD.ORG Subject: Re: panic: zone: entry not free References: <199903101649.LAA26851@khavrinen.lcs.mit.edu> <199903101722.MAA27037@khavrinen.lcs.mit.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :We were talking about invariants, which document the conditions which :nearby code expect and/or cause. To actually check these conditions :in a production system is a waste of CPU power; their function is to :define for the developers precisely what the expected outcome of a :particular operation is, so that new bugs are not introduced when code :is modified. : :-GAWollman : :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same I would not characterize the use of invariants in production kernels as being a waste of cpu power... I'm sure there are many people who are more interested in data integrity then in performance. The use of inviariants can conceivably catch a problem early that might otherwise corrupt the system later. On the otherhand, the speeddaemons might not want either the invariants or the standard sanity checks, in which case they do not turn on invariant support and they do turn on MAX_PERF ( which gets rid of most of the standard sanity checks ). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message