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

[christos%zoulas.com@localhost (Christos Zoulas)]

On Dec 23, 10:04am, thorpej%me.com@localhost (Jason Thorpe) wrote:
-- Subject: Re: Current best practice for testing a new kernel API?

| A downside I see to the rump option... as far as I can tell, rumpkern is bu=
| ild 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 lifecyc=
| le, there are cases in the code where the API might work fine, but invarian=
| ts are violated leading to "weird" behavior later, so I want those invarian=
| ts to be checked in the normal course of testing.

I don't know why that is. Perhaps it is not good for production use because
of the extra messages and slowdown. The problem is that the rump server can
be used for both?

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

Or turn on DIAGNOSTIC in rump and see what breaks...

christos