Skip site navigation (1)Skip section navigation (2)
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>