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

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

> On Dec 23, 2018, at 9:34 AM, Martin Husemann <martin%duskware.de@localhost> wrote:
> 
>> For completeness, I'll explore the rump option
> 
> That is definitively the prefered way. One example is npf usint it to
> test custom kernel test code, but that overall is a bit ... complex.

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.

I suppose I can define my own assertion macro in kern_threadpool.c dependent on _RUMPKERNEL ... but that doesn't seem ideal, either.

-- thorpej