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

[Gedare Bloom]

Hi Philipp,

On Wed, Mar 5, 2014 at 3:48 AM, Philipp Eppelt
<philipp.eppelt at mailbox.tu-dresden.de> wrote:
> 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.
>
Thanks for pulling these issues out.

> 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?
>
I'm not satisfied with this solution. It assumes the pok sources are
the same as the ones used to build the libpart.a. Can the required
header files from pok be packaged with the libpart.a? Some other
options would be nice to consider.

Gedare

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