Including paravirtualization headers in RTEMS

[Gedare Bloom]

On Tue, Jun 3, 2014 at 3:15 AM, Chris Johns <chrisj at rtems.org> wrote:
> 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
This was also the design I used when refactoring the scheduler. I
think it could work for directing ARINC calls, and it also would
enable other arinc-compliant partitioning OSs to be used even if their
interface differs a bit from POK.

-Gedare