[PATCH] i386/virtualpok BSP, virtual BSP to be used with POK, build with enable-paravirt

[Philipp Eppelt]

Hi,

as of now it looks like we have a student picking up my work from last
year. While the patches for the --enable-paravirt configuration option
went upstream, the virtualpok BSP for i386 still has open issues.

I reviewed the discussion we had in December and January on the
virtualpok BSP for i386. We ended with the following two issues:

* Extension of --enable-paravirt to pass along /path/to/libpart.a (in POK)
* How can we ensure that the POK and RTEMS virt.layer header files don't
diverge.

The first point is clear. The second is complicated. From the design
point of view, the BSP should communicate transparently with the host.
This transparency is provided via the two header files
virtualizationlayer{cpu|bsp}.h . The missing implementation has to be
provided by the host, otherwise the BSP can't be build. Which is quite
okay, as this failure is exactly telling you what is missing.

However, if our or the host side is changing and the changes aren't
propagated to the other side, it is difficult to track and find the error.
Can we build in some checks?
I don't think one could force POK to check for updates at compile time.
However, I can imagine a script being build after
--enable-paravirt=/path/to/libpart.a is configured, which determines the
correct location of virtualizationlayer{cpu|bsp}.h in POK and diff these
files with the BSP local definition.

e.g.:
ret = diff virtualpok/include/virtualizationlayerbsp.h
/path/to/libpart.a/../../../virtualizationlayerbsp.h
if( ret != 0 ) print ERROR
***
Can we integrate such a script into a generated makefile? Or is it
sufficient to just provide this script and describe it in the BSP's readme?


Another question is if the linker is checking the full header? The
function name and all parameter types? Wouldn't this be sufficient to
alert the user of inconsistencies?


Automated testing is a third issue. But I'd like to postpone this, until
we actually have something that can be tested.


Cheers,
Philipp