Re: kernel api testing with atf and rump ?

[Cherry G. Mathew <cherry%zyx.in@localhost>]

>>>>> "Martin" == Martin Husemann <martin%duskware.de@localhost> writes:

    Martin> On Sun, Jun 17, 2012 at 07:13:01PM +0100, Cherry G. Mathew wrote:
    >> - does the default atf source tree contain a generic rump build
    >> that provides most/all api translations to userland.

    Martin> Yes, this part is trivial.

    >> - is there a quick and dirty way I can test a trivial api such as
    >> kern_add.c above.

    Martin> For this, however, I do not know an easy way. I experimented
    Martin> with a shared library linked as part of the rump kernel and
    Martin> a separate executable loading it and invoking a test
    Martin> function in it.

It looks like the only issue here is the use of kernel headers in the
test code/ "application part"(in rump speak) itself. Per Antti's
"Kernel Development in Userspace - The Rump Approach" paper, namespace
collisions between kernel space and userspace means that the application
part has to either re-define the kernel APIs it uses (with the namespace
prefix rumpns_xxx) or have a "bridge" layer do this for you.

I'm wondering if we define a policy wrt headers, where specific system
headers only import *OR* export apis to consumers, the problem can then
be compartmentalised a bit more.

One way to do this might be to mandate that api importing is only done
via .c files. 

In my earlier trivial example, let's say we had provided the
api via prototyping in sys/add.h

int add(int, int);

......

kern_add.c would then do the requisite:

#include <sys/cdefs.h>
#include <sys/add.h> /* Assume for the minute, that add.h needed cdefs.h */
....

I know this is non-trivial, but I'd like to understand the problem
further. For eg: has this been tried before ? Is it possible to have a
source tree that provides api headers that  doesn't have to protect
itself from recursive includes via "#ifndef _MYHEADER_DEFINE_ / #endif"
blocks ? etc.

Again, I'm looking for education via pointers/prior art/discussion.

Cheers,
-- 
Cherry