Date: Tue, 18 Dec 2012 13:36:16 +0100 From: Andre Oppermann <andre@freebsd.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, Adrian Chadd <adrian@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org Subject: Re: svn commit: r244112 - head/sys/kern Message-ID: <50D06340.5020904@freebsd.org> In-Reply-To: <50CF98DB.1050102@FreeBSD.org> References: <201212110708.qBB78EWx025288@svn.freebsd.org> <50CBC285.7060307@mu.org> <20121215161414.V1029@besplex.bde.org> <201212171439.27297.jhb@freebsd.org> <50CF8CE7.4020906@mu.org> <50CF92F0.5020904@FreeBSD.org> <CAJ-VmonBP5chxPROAQya8ckmLzJrMRK%2B2qD_SKpROJO=T71_Kw@mail.gmail.com> <50CF98DB.1050102@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17.12.2012 23:12, Andriy Gapon wrote: > on 18/12/2012 00:02 Adrian Chadd said the following: >> Why are they there, if we just ship production releases with >> INVARIANTS disabled? > > Because there is an axis orthogonal to asserting correctness - performance. Indeed. There are, or will be, a couple of very intrusive and expensive mbuf and socket buffer integrity checks under KASSERT/INVARIANTS that are not appropriate and performance reducing for productions kernels. The same goes for UMA memory fuzzing. I've always used and placed KASSERTs with this assumption. I do have some sympathy for a certain run-time KASSERT() check that will print a backtrace but won't panic. However it is a distinct class from what we have now and needs to be explicitly placed by the programmer to make sense with the logic around it. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50D06340.5020904>