Re: kasserts behind invariants
On Friday, December 13, 2013 4:50:25 pm Sean Bruno wrote: I guess this may have been argued before, but I don't see why we would want to hide specific things like: sys/kern/subr_lock.c /* Check for double-init and zero object. */ KASSERT(!lock_initalized(lock), (lock \%s\ %p already initialized, name, lock)); If I hadn't completely missed the fact that I had INVARIANTS activated, I'd never have found out why this vendor driver was being so completely stupid and crashing my machine. If I find things like this that I want old KASSERT behavior on (panic if true) and I don't want to run INVARIANTS, is that possible? KASSERT has never been enabled sans INVARIANTS. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
kasserts behind invariants
I guess this may have been argued before, but I don't see why we would want to hide specific things like: sys/kern/subr_lock.c /* Check for double-init and zero object. */ KASSERT(!lock_initalized(lock), (lock \%s\ %p already initialized, name, lock)); If I hadn't completely missed the fact that I had INVARIANTS activated, I'd never have found out why this vendor driver was being so completely stupid and crashing my machine. If I find things like this that I want old KASSERT behavior on (panic if true) and I don't want to run INVARIANTS, is that possible? sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kasserts behind invariants
On 12/13/13 1:50 PM, Sean Bruno wrote: I guess this may have been argued before, but I don't see why we would want to hide specific things like: sys/kern/subr_lock.c /* Check for double-init and zero object. */ KASSERT(!lock_initalized(lock), (lock \%s\ %p already initialized, name, lock)); If I hadn't completely missed the fact that I had INVARIANTS activated, I'd never have found out why this vendor driver was being so completely stupid and crashing my machine. If I find things like this that I want old KASSERT behavior on (panic if true) and I don't want to run INVARIANTS, is that possible? I don't understand the question, do you want to move it from INVARIANTS to under just a plain if(condition)? -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kasserts behind invariants
On Fri, 2013-12-13 at 14:43 -0800, Alfred Perlstein wrote: On 12/13/13 1:50 PM, Sean Bruno wrote: I guess this may have been argued before, but I don't see why we would want to hide specific things like: sys/kern/subr_lock.c /* Check for double-init and zero object. */ KASSERT(!lock_initalized(lock), (lock \%s\ %p already initialized, name, lock)); If I hadn't completely missed the fact that I had INVARIANTS activated, I'd never have found out why this vendor driver was being so completely stupid and crashing my machine. If I find things like this that I want old KASSERT behavior on (panic if true) and I don't want to run INVARIANTS, is that possible? I don't understand the question, do you want to move it from INVARIANTS to under just a plain if(condition)? -Alfred ___ In this specific instance, it would have been much better to simply panic if(condition) than silently allowing the vendor driver to do something stupid like initialize a mutex twice. sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kasserts behind invariants
on 14/12/2013 01:05 Sean Bruno said the following: In this specific instance, it would have been much better to simply panic if(condition) than silently allowing the vendor driver to do something stupid like initialize a mutex twice. I like Solaris/illumos approach of having ASSERT and VERIFY macros. ASSERT is compiled out when DEBUG is not set while VERIFY is always kept. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
