Re: kasserts behind invariants

2013-12-23 Thread John Baldwin
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

kasserts behind invariants

2013-12-13 Thread Sean Bruno
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

Re: kasserts behind invariants

2013-12-13 Thread Alfred Perlstein
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,

Re: kasserts behind invariants

2013-12-13 Thread Sean Bruno
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. */

Re: kasserts behind invariants

2013-12-13 Thread Andriy Gapon
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