Including paravirtualization headers in RTEMS

[Chris Johns]

On 3/06/2014 10:38 am, Janek van Oirschot wrote:
> First off, sorry for the late response to this.
>
> On Mon, May 26, 2014 at 8:46 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>
>> I would guess most of the partition services will be related to some
>> standard e.g. ARINC/FACE, so that might be a useful place to start
>> when considering what the RTEMS API to the partitioning kernel should
>> look like.
>
> I'm currently working on ARINC 653 compliance on RTEMS through POK and
> I've thought about creating an RTEMS API that allows for ARINC 653
> calls, which in the current situation just forwards calls to POK. The
> problem that arises with this is that if in the future native ARINC
> 653 compliance is implemented within RTEMS it will conflict with
> partitioned kernel API ARINC 653, if you know what I mean. I.e. when
> calling any ARINC 653 call, which must it choose? native ARINC 653?
> Virtualized ARINC 653? Well, this isn't as big of a "problem" because
> you could solve it but I'm not sure what would be best option to solve
> this.
>

Is it possible to develop an RTEMS ARINC 653 API and implement runtime 
binding via a const function table. The file system is an example of 
this with its file ops table but this is simpler because you only have 
one instance active at runtime therefore one table pointer referenced 
from the RTEMS ARINC API.

This approach allows for different implementations and even late binding 
with the code linked externally when the application is linked.

Chris