On 16 December 2012 15:32, Navdeep Parhar <npar...@gmail.com> wrote:
>> The status quo _does not change_ by default. > > So now we have a knob that could be used to change the behaviour of all > the KASSERTs in the system; one that hints that it may be possible to > continue even if an assertion in the FreeBSD kernel doesn't hold good > (this is the part that bothers me). I know all the KASSERTs I've looked > at or written are genuine assertions -- the code simply wouldn't be able > to cope if they were violated. You'd get NULL dereferences, or worse, > access protected structures without corresponding locks held, etc. In that case, those failures should be handled gracefully, or they should immediately panic the kernel. Claiming that a KASSERT() is optional at this point is basically us as a project saying "We know that if the kernel gets to this point and it fails this check, everything is busted after this." Ie, "Hey, if you disable KASSERT(), your data is potentially toast." Yet we ship with KASSERT() disabled. Silent data corruption, race conditions, etc. Not everything leads to a NULL pointer dereference. Again, we ship with KASSERT disabled in GENERIC on shipping production releases. The concerns you have with KASSERT printing out when Alfred's modification is enabled -does not change the fact that the kernel does _EXACTLY THIS_ kind of "oh well, I'll keep going" behaviour in a GENERIC, production, release kernel-. Adrian _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
