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