> On Dec 23, 2018, at 9:34 AM, Martin Husemann <[email protected]> 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
