Re: Current best practice for testing a new kernel API?

[Jason Thorpe <thorpej%me.com@localhost>]

> On Dec 23, 2018, at 10:04 AM, Jason Thorpe <thorpej%me.com@localhost> 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