ARINC-653 API

Fri Mar 16 16:33:47 UTC 2012

On 03/16/2012 11:22 AM, 张文杰 wrote:
> Hi Joel, I am very sorry for making you mistake. That AIR use PMK instand of
> POK. PMK is hyper visor kernel which response for scheduling. 
>
OK. Doesn't change the basic premise of my response.

+ Your work needs to be in a state to merge.
+ We need to reproduce your testing independently.
+ Paravirtualized BSPs are good things.
+ Pok support is desirable.
+ ARINC-653 support is desirable.
+ Is there a way to have a paravirtualized BSP which
could run on different hypervisors?

The last point is easy to gloss over but is desirable because
then we would only have one BSP to support long term. Even
if some code differed, structuring the BSP to make this happen
would be of benefit.

--joel
> 在 2012-03-16 23:14:29，"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
>
>
>
>

-- 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120316/c1cd1716/attachment-0001.html>