Re: Only userland?

["Perry E. Metzger" <perry%piermont.com@localhost>]

"Julio M. Merino Vidal" <jmerino%ac.upc.edu@localhost> writes:
> But I bet there are still some scenarios were we might be interested
> in unit-testing kernel code at the kernel level either because it is
> very hard to do in user-space or simply impossible.  Certainly that
> has a lot of risks (and a lot really means a lot), but it may be an
> interesting thing to have (and to code :-).

Arguably, one should try very hard to have as much code as possible
unit testable inside a userland framework.

However, as you note, that is not always possible. I suspect that
simulators, like qemu, might play a role here for code that really
cannot be run in userland. A special module could then be used, or
qemu could be "puppeted" via gdb scripts, or perhaps both at once.

So, I suppose I'm agreeing with what you say below. :)

> My idea for that is along the lines of having a kernel module, say
> atf.ko, that provides some functions* to let the testing code
> register test cases and provide logging to userspace (not through
> printf and dmesg).  Then make the user define his own modules (e.g.
> in_cksum.ko) that provide unit testing for specific bits (depending
> on atf.ko for the base functionality).  At last, make atf provide a
> transparent way to automatically load the module, run the test cases,
> get the log and unload the module.  (For safety, we would need to be
> able to run these critical tests remotely or in a VM, as I have
> already mentioned some times for delicate user-space tests that can
> crash the kernel anyway.)
>
> Do you think that'd be good to have?
>
> Kind regards,
>
> * Yes, these could have to be written in plain C and they could be
> the foundation for a future user-space C-only binding (thus ditching
> the need of C++ in the test cases).
>

-- 
Perry E. Metzger                perry%piermont.com@localhost