libl4 test cases

[Marcus Brinkmann]

Hi,

I just added a rudimentary test framework to libl4.  You can find it
in libl4/tests/.  It is pretty simplicistic, but I already emulate the
kernel_interface system call, and more system calls can be emulated
with a bit of hacking (in fact, all the other system calls can be
emulated without changing the libl4 source by writing emulating system
call stubs, which would be architecture specific and obey the L4
calling conventions.

Currently, the test suite only compiles on ia32.  Support for other
arches can be added.  Things like word sizes, endianess, and arch
extensions make it necessary I think to "port" the test suite and test
it on each platform individually.  I don't think it is a big problem.

Currently, all interfaces are enabled (GNU and L4 compat).  However,
compile problems that are only visible if one of the interfaces is
disabled are hidden this way.  All tests should be protected by
ifdef's so we can later make it configurable and compile the test
suite with different interfaces selected.

cookin, racin: I know you wrote test cases (for time and string item
operations).  It would be great if you could polish your code (follow
my t-l4-kip.c for how to use the test environment), and send us a
patch that adds more tests to our libl4.

To everybody else: Writing test cases for libl4 is an isolated task
that can be anything from very easy to medium (depending on what you
want to test).  No Hurd knowledge is required.  You need to understand
the L4 spec though (at least for those parts you want to write tests),
and be able to do a bit of C hacking.  Many functions in the library
are very small and have a very constraint interface and functionality,
so there are many easy candidates for thorough testing.  On the
downside, there are many, many of those functions in the library, so
many tests have to be written.

These tests are important!  They are important because the functions
in libl4 are all inlined, so many errors, even syntactical ones, are
not visible until you actually try to use and compile them.  libl4 is
not a library that is "built", it is just used.  So we have to use it
to find the bugs!  The more systematically we test the library, the
better.  It's a good way to get rid of potential error sources which
are very hard to track down once you build real world applications
from the primitives.

(There are IMO only two ways to write good tests: Either you pick an
interface and write very systematic tests that try to check all
aspects of the interface, or at least the most common uses and the
important border cases.  Or you find a bug and write a test case
specifically for the bug to make sure it never comes back undetected
again.  Both are welcome.)

address@hidden:~/gnu/hurd/work/hurd-l4-build/libl4/tests$ make check
make  check-TESTS
make[1]: Entering directory 
`/space/home/marcus/gnu/hurd/work/hurd-l4-build/libl4/tests'
[intern] Checking if fake KIP is installed... OK
[intern] Checking if fake API version matches KIP... OK
[intern] Checking if fake API flags matches KIP... OK
[intern] Checking if fake kernel ID flags matches KIP... OK
[GNU] Checking if l4_kip() returns the KIP... OK
[L4] Checking if L4_KernelInterface returns the KIP... OK
[L4] Checking if L4 API version matches KIP... OK
[L4] Checking if L4 API flags matches KIP... OK
[L4] Checking if L4 kernel ID flags matches KIP... OK
PASS: t-l4-kip
==================
All 1 tests passed
==================
make[1]: Leaving directory 
`/space/home/marcus/gnu/hurd/work/hurd-l4-build/libl4/tests'

Thanks,
Marcus