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 <ged...@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
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
