ARINC-653 API
Gedare Bloom
gedare at rtems.org
Sat Mar 17 04:00:14 UTC 2012
On Fri, Mar 16, 2012 at 3:14 PM, Cláudio Silva <claudiodcsilva at gmail.com> wrote:
> In the paravirtualization project you need to account for several
> complex things. e.g. memory model of the underlying hypervisor,
> removing supervisor mode "things", interrupt virtualization, etc. This
> gets even more complex if you want a hypervisor-independent layer/BSP
> and different HW architectures.
>
> I feel that the key point for RTEMS in this project is hypervisor
> independence. Focusing on only one hypervisor is wrong.
> Besides this, I also think that the role of providing these
> BSPs/Layers should be from those who develop the hypervisors. They
> should contribute the changes they made to RTEMS or at least make them
> available even if not "merged" to RTEMS.
>
Agreed. Paravirtualization ought to factor out the
privileged/protected instructions and provide an RTEMS interface that
can wrap hypercalls to whatever VMM will be used. The specifics of the
hypercalls should be pluggable for any particular hypervisor.
> Now regarding the ARINC 653 API implementation. Most of the services i
> mentioned in my previous email have almost perfect correspondence with
> RTEMS or POSIX services already available. Therefore even if you don't
> want the ARINC653 API implemented as a wrapper to the classic API,
> there would be a lot of code reusable from other APIs.
> In a quick overview (i am probably missing somethings) :
> - Processes: ARINC processes are priority based. There are periodic
> and aperiodic processes. The process period is given when the process
> is created and then the process can do such things as
> "periodic_wait()" to sleep and only be awaken at next periodic release
> point. Although there is no direct match to the classic or posix API,
> this implementation shouldn't prove very hard.
> - Time Management: Services to obtain monotonic time with nsec
> precision (similar to rtems_clock_get_uptime()), to wait for an amount
> of time (similar to rtems_task_wake_after()) and related to process
> periodicity (periodic_wait and replenish) .
> - Buffers: Message queues (FIFO) of a given size. Processes can block
> in them and are awaken in priority or FIFO order.
> - Blackboards: Single message queue. One writer, several consumers.
> Reading processes can block and are all awaken at the same time on
> write.
> - Semaphores. Counting Semaphore (priority or FIFO). Similar to
> rtems_semaphores.
> - Events. These are similar to binary conditions. (similar to
> pthread_cond / cond_broadcast)
> - Error Handling: This would need to be better analyzed.
>
> In my opinion a good GSOC project would be implementing (and
> merging!!) these services and providing documentation . If there is
> time remaining one could start to approach coverage.
> I think that for the "ARINC 653 community" it only makes sense to
> test the full system, and for that you require an underlying
> hypervisor. The"ARINC 653 community" generally has the resources to do
> their own validation testing.
>
This sums up things nicely, although the amount of work might be large
for a gsoc project.
> Regarding the standard availability, maybe the student can obtain it
> at his university library..
>
> (sorry for the long text :P)
> Cláudio.
>
> 2012/3/16 Joel Sherrill <joel.sherrill at oarcorp.com>:
>> Well stated Claudio.
>>
>> I am not sure about the time required for an ARINC-653 API
>> versus the paravirtualization project though.
>>
>> To be done correctly, the API task one would need to have
>> access to the standards, implement the APIs, implement
>> full coverage tests of those APIs, and write a manual.
>> The API would need to be implement as a peer with the
>> Classic and POSIX threading APIs not as a wrapper. That
>> increases the complexity some. It may involve tinkering
>> with Score capabilities if they do not map directly into
>> ARINC 653 services.
>>
>> All of the above is just to meet the minimum technical goal.
>> IMO an ARINC-653 API implementation would also need to
>> address requirements traceability from the standard to
>> code and tests so we meet the best practices expected by
>> users in the ARINC 653 community.
>>
>> In contrast, the paravirtualized BSP could be restricted
>> to ensuring that the AIR BSP from last year works on both
>> AIR and Pok using a common BSP. And that the layering
>> and compartmentalization you describe is proper. There is
>> some documentation and test required here but not near
>> as much. And the requirements traceability is not as critical.
>>
>> --joel
>>
>> On 03/16/2012 11:31 AM, Cláudio Silva wrote:
>>> Hi,
>>>
>>> 张文杰 mistyped. AIR is based on PMK and not on POK.
>>> If i remember correctly the developed BSP was not included in RTEMS
>>> because it included changes to other "places" than just libbsp.
>>>
>>> I personally agree with Julien, The best project for RTEMS is to
>>> provide a hypervisor-independent paravirtualization layer to which
>>> several hypervisors can attach to. The student shall determinate which
>>> points in RTEMS source need to be virtualized through hypervisor
>>> calls. The best way to achieve this is through porting RTEMS to POK
>>> and by analyzing AIR RTEMS's patch (available in 张文杰 delivery).
>>>
>>> Part of the ARINC653 API (processes, time management, buffers,
>>> blackboards, semaphores, events and partially error handling) can be
>>> provided without an underlying Hypervisor. The remaining services
>>> (health monitoring, ports and partition management) can be abstracted
>>> to the services provided by any underlying hypervisor. You can also
>>> include the ports service in standalone mode if you map the ARINC
>>> ports to UDP ports (but then you need to use the ip stack...) [i see a
>>> possible use case of this if someone wants to use pseudopartitions on
>>> a distributed ARINC653 system].
>>> I think this ARINC653 API project is more feasible than the
>>> paravirtualization one and also fits best on a GSOC timeline.
>>>
>>> Regards,
>>> Cláudio
>>>
>>> 2012/3/16 Joel Sherrill <joel.sherrill at oarcorp.com>:
>>>> On 03/16/2012 09:14 AM, 张文杰 wrote:
>>>>
>>>> Hi, all:
>>>> I am the student who implement the GSOC2011 project hypervisor for
>>>> RTEMS.
>>>> In my original proposal i wanted port the linux to the RTEMS
>>>> paravirtualization hypervisor
>>>> named AIR. But as the progress of project, the plan had changed into adapt
>>>> the
>>>> lastest RTEMS to the AIR hypervisor. So what i did is make the lastest RTEMS
>>>> run
>>>> under AIR successfully which contains a paravirtualization RTEMS kernel
>>>> named
>>>> POK. If you want to know any information please free to contact me
>>>>
>>>> :) We are very interested. I didn't realize that AIR used Pok. Since I
>>>> couldn't
>>>> get access to AIR, I was refocusing on Pok. Julien Delange is responsible
>>>> for
>>>> Pok.
>>>>
>>>> We would like to see RTEMS as a proper client under Pok and eventually
>>>> support the ARINC-653 API that way. So getting your BSP into proper shape
>>>> on the RTEMS head and making sure others can run it is a BIG deal.
>>>> From there, we can begin to support other architectures supported by Pok
>>>> and provide application level ARINC services.
>>>>
>>>> At 2012-03-16 06:47:16,"Julien Delange" <julien.delange at gmail.com> wrote:
>>>>> On Thu, Mar 15, 2012 at 6:44 PM, WL <jolkaczad at gmail.com> wrote:
>>>>>> This is all valuable stuff, and the topic is getting more interesting
>>>>>> by the minute. I see that this would somewhat pick up where a last
>>>>>> year's GSoC project left off. Is the student still active in the
>>>>>> community? If not ,did he leave his work in a useable state? I'd like
>>>>>> to contact him since there's no need to do the same research again and
>>>>>> come to conclusions which have already been arrived at.
>>>>> Hello,
>>>>>
>>>>> Please have a look the the links below. Also, the whole project has
>>>>> several goals :
>>>>> 1. Implement ARINC653 services in RTEMS. If you consider RTEMS only,
>>>>> you can only design intra-partition services (tasks, intra-partition
>>>>> comm. , etc ...). This is described in [3].
>>>>> 2. Implement a prototype of a hypervisor to execute several RTEMS
>>>>> instance in different partitions (see proposal [4]). In that case, the
>>>>> work consists in (1) design a first prototype to execute RTEMS in
>>>>> several partition and (2) adapt RTEMS to call the hypervisor services
>>>>> for inter-partitions interactions. Once that is done, we can also
>>>>> implement ARINC653 inter-partitions services.
>>>>>
>>>>> So, implementing full ARINC653 compliance for RTEMS would require to
>>>>> do both tasks. The second project is more difficult but has more
>>>>> priority since this would be the fundation for building partitions
>>>>> using RTEMS. In addition, making the partitioned-bsp of RTEMS would be
>>>>> really tricky because it has to be as much generic as possible to fit
>>>>> with other separation kernel approaches (as AIR, XtratuM or POK).
>>>>>
>>>>> As far as I know, the GSOC 2011 project focuses on the second item of
>>>>> the work. It was based on AIR but unfortunately, it does not seem
>>>>> available (you can check on http://air.di.fc.ul.pt/). However, the
>>>>> report of this work is available as gdoc documents, you have to
>>>>> request access to it, links to ask are located on page [2]. Also, Joel
>>>>> may have more information about the status of the 2011 GSOC project
>>>>> related to this topic.
>>>>>
>>>>> Hope that helps,
>>>>>
>>>>> [1] http://wiki.rtems.org/wiki/index.php/RTEMSHyperVisor
>>>>> [2] http://wiki.rtems.org/wiki/index.php/RTEMSSummerOfCode2011
>>>>> [3] http://wiki.rtems.org/wiki/index.php/ARINC653API
>>>>> [4] http://wiki.rtems.org/wiki/index.php/RTEMS_Paravirtualization
>>>>> _______________________________________________
>>>>> rtems-users mailing list
>>>>> rtems-users at rtems.org
>>>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Joel Sherrill, Ph.D. Director of Research& Development
>>>> joel.sherrill at OARcorp.com On-Line Applications Research
>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>>> Support Available (256) 722-9985
>>>>
>>>>
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>>
>>
>>
>> --
>> Joel Sherrill, Ph.D. Director of Research& Development
>> joel.sherrill at OARcorp.com On-Line Applications Research
>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>> Support Available (256) 722-9985
>>
>>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
More information about the users
mailing list