Including paravirtualization headers in RTEMS

Chris Johns chrisj at
Tue Jun 3 07:15:00 UTC 2014

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

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


More information about the devel mailing list