On Tue, Jun 3, 2014 at 3:15 AM, Chris Johns <chr...@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 <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 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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
