ATF-devel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Only userland?



On Feb 6, 2008, at 2:14 AM, Perry E. Metzger wrote:


Martin Kulas <MartinKulas%sosend.de@localhost> writes:
On Tue, Feb 05, 2008 at 11:19:50AM +0100, Martin Husemann wrote:
Slightly unrelated: look at src/regress/sys/net/in_cksum.c for a pure userland test of kernel code (not very polished, we shoul realy do better).

This is a nice idea to handle mbuf{} in user space.

This is clearly a good idea -- ideally, I think one wants userland
unit tests for major kernel data structures.

Certainly we want to test as much kernel code as possible directly from userland, and we are getting lots of different ways to do it. As I mentioned: rump, puffs, pud, NetBSD/usermode or simply rebuilding kernel code as part of a userland program as done by this in_cksum test. I'm still unsure how some extra functionality in ATF itself could help here, though, because using these techniques is not transparent at all and are very tied to the specific test you are implementing.

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 :-).

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).



Home | Main Index | Thread Index | Old Index