Date: 10 Mar 1999 17:57:43 +0100 From: Dag-Erling Smorgrav <des@flood.ping.uio.no> To: sthaug@nethelp.no Cc: dillon@apollo.backplane.com, dcs@newsguy.com, Jos.Backus@nl.origin-it.com, dima@tejblum.dnttm.rssi.ru, perhaps@yes.no, freebsd-current@FreeBSD.ORG Subject: Re: panic: zone: entry not free Message-ID: <xzpiuc97054.fsf@flood.ping.uio.no> In-Reply-To: sthaug@nethelp.no's message of "Wed, 10 Mar 1999 17:26:59 %2B0100" References: <xzplnh57340.fsf@flood.ping.uio.no> <28892.921083219@verdi.nethelp.no>
next in thread | previous in thread | raw e-mail | index | archive | help
sthaug@nethelp.no writes: > > Uh, no. Invariants are for developers who want to make sure their code > > is correct. There is no reason why an end user would want to build a > > kernel with invariants enabled. Invariants will *not* increase data > > safety. If they have any effect at all (i.e. if they actually catch a > > bug), the result is a panic (whereas with a kernel without invariants, > > the bug might actually go unnoticed). > So for the end user it's better to have the bug go unnoticed than to > get a kernel panic and notice the bug? Please tell me I'm misunder- > standing something here. No, it is not - not in the general case, and not in the long term. I was trying to point out that there may be extreme cases where an otherwise harmless bug would cause a panic with invariants enabled. Matt claimed that invariants increase data safety, which I find difficult to understand. The only possible value an end user could derive from a kernel with invariants is a backtrace to attach to a send-pr. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpiuc97054.fsf>