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

[Chris Johns]

On 8/03/2014 12:38 am, Philipp Eppelt wrote:
>
> For the next design, I would be very interested to hear the expectations
> and requirements up front.

The ideal situation is POK being built without any specific detail of 
RTEMS and RTEMS POK support is implemented for a supported architecture 
and a BSP within the architecture.

We should treat POK as a binary black box when looking from RTEMS. RTEMS 
makes calls to a specific and agreed interface and POK responds in a 
defined manner.

This approach means the tools and options used to build POK and RTEMS 
can vary independently. The only requirement is the resulting code 
generated meets the ABI.

When I mean ABI I mean the machine level.

> So we don't have to go through this discussion again.

I agree.

> Questions like:
> Are we allowed to have dependencies to the host(POK)?

Yes at an ABI level that defines the calls to POK. RTEMS needs to 
contain code that implements these calls.

> Which dependencies are allowed?

Consider how we would need to maintain the continuous integration server 
so this can be tested.

We need a suitable POK version and we would assume this is a stable 
released version that is approved for RTEMS. There may be RTEMS specific 
patches as version skew between the upstream POK and RTEMS move around. 
POK is considered stable and should not vary in the short to medium 
term. The POK build system would need to support the RTEMS server farm 
operating system which is FreeBSD. You can consider the POK dependency 
as being similar to the tools for RTEMS and how they are handled. If POK 
needs specific tools or other libraries these dependences would need to 
be added to the list. I would not expect to be building POK each time we 
build and test RTEMS.

If the interface code which is currently called libpart.a was in RTEMS 
we would have no further dependences. The way the code is built and how 
it is built is contained in RTEMS so a change in build flags would 
effect the BSP, RTEMS and this code. If this code is separate from POK 
and RTEMS we would need to build this code with the tool set we would be 
using to build RTEMS and the same flags (or close to the same flags). We 
would also need to manage the dependence between the build flags used 
for both libraries. Some architectures have flags that vary the ABI, eg 
hard vs soft float. If this code resides in POK we would have RTEMS 
dependent on POK and POK dependent on RTEMS and that is not my preferred 
path.

> Which dependency checks need to be in place?

The ABI version in POK and the version in RTEMS. I suspect this would be 
a runtime check. It the libpart.a is separate another check for its 
version would be needed and maybe the flags used to build it (I have no 
idea how you would do this).

If the ABI changes we need a new version number to check and a new POK 
and updated code in RTEMS (if libpart.a was in RTEMS). If the RTEMS 
build flags or new tools breaks the ABI on the RTEMS side that is a bug 
and our testing should show this. A new POK needs to have been tested 
against a known RTEMS version and so the ABI tested before it is 
released and we use it for our testing.

I hope this helps.

Chris