> On Dec 23, 2018, at 10:04 AM, Jason Thorpe <[email protected]> wrote:
>
> A downside I see to the rump option... as far as I can tell, rumpkern is
> build with no DIAGNOSTIC, so all of the KASSERT()s in kern_threadpool.c will
> never get a chance to fire. At least the module approach will tickle that
> code path, at least for -current GENERIC. Especially around object
> lifecycle, there are cases in the code where the API might work fine, but
> invariants are violated leading to "weird" behavior later, so I want those
> invariants to be checked in the normal course of testing.
Oops, my mistake, it is apparently build with -DDIAGNOSTIC ... so, ok, I'll do
a rump-based unit test.
-- thorpej
