On Feb 4, 2008, at 11:19 PM, Martin Kulas wrote:
On Sun, Feb 03, 2008 at 05:56:37PM +0100, Julio M. Merino Vidal wrote:I am interested to know what you would need in ATF to be able to do that (i.e., the "write tests for my custom functions which run in kernel space" part). The way I see it, you should either write a kernel module with the testing code, load it, get the results (or crash), and unload it (which you can already do with ATF, but manually). Or you'd just recompile the code as a userland binary anduse it in the tests (as NetBSD's rump allows). Or... your approach? :-)I wrote a kernel module and tested my code by using printf(9). I automated the testing process by parsing the dmesg(8) output ...
I see. You'd easily plug that in into an existing ATF test suite, even though it could not simplify things too much -- other than providing standarized reporting of results. Basically, an ATF check for what you mention would be like:
mbuf_head() {
set "descr" "My tests for the mbuf kernel function"
}
mbuf_body() {
... load kernel module ...
... fire kernel-side tests ...
... dump kernel output into a "kern.log" file ...
# Process the kern.log file
atf_check 'grep blah kern.log' 0 ignore null
...
}
mbuf_cleanup() {
... unload kernel module ...
}
The only part where ATF helps here is in the part where you process
kern.log, and again it provides you a command line interface that
would be consistent with all the other tests in your test suite (be
them kernel level or user level).
But... I think we'd do better. ATF could provide you a kernel-level interface to write your module (similar to the current user-level interface) and a way to easily report the results to user space (through a pseudo-device, or procfs file, or whatever). Then, if these modules were in a consistent format known by ATF (much like the current user-level test programs), all the boilerplate code shown above could be simplified or completely eliminated.
Mmm, the more I think on this, the more I find this idea interesting. The only problem is that the framework itself will be near to impossible to be portable. But hey, as the ROADMAP states, extreme portability is not a goal :-)
Would that be any useful to you? Kind regards.