GSoC2014 proof of running RTEMS + GSoC project option(s)

[Gedare Bloom]

On Sun, Mar 16, 2014 at 5:49 PM, Janek van Oirschot
<janekvoirschot at gmail.com> wrote:
> Hello,
>
> On Sun, Mar 16, 2014 at 6:08 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>
>> That student is focusing on the effort to get RTEMS working within
>> Pok. Implementing arinc 653 interfaces in RTEMS might still be useful.
>
> I wouldn't mind implementing ARINC653 or ARINC653-p4 for RTEMS. The
> problem would be that the specs aren't available. The way I
> interpreted Joel's response to my ARINC 653 question mail was that the
> paravisualization project would allow ARINC653 compatibility in
> combination with RTEMS simply because POK is ARINC653 compliant. This
> would allow some partitions to use ARINC653 and one (or more?)
> partitions to run and use RTEMS.
>
I don't know if an ARINC-653 spec can be gotten for you or not. I
haven't looked at the prospect of implementing ARINC-653 services in
about 2 years, but I recall there are some kind of APEX API or
something that it makes sense to support in the partition, that the
application code can call, and that RTEMS would probably forward on to
POK.

>> You may like to describe your own project if you have one that
>> interests you in mind.
>
> Augh, it's always hard for me to think of a project (definitely on
> such a short notice, sorry!). I have the idea of porting (µ)AFDX
> (AIRBUS implementation of ARINC 664) to RTEMS. But this is one of
> those ideas that are hard to realize because there's no free (µ)AFDX
> stack available and no specification available to implement a stack.
>
Without something to reference, this seems an unlikely project to me.

>> I don't know if anyone cares about that TIPC or not. The AIO calls
>> were worked on in a prior GSoC so you would have to see what if
>> anything remains to be done there.
>>
>> An area that has not received much attention yet is the RTEMS Tester:
>> http://wiki.rtems.org/wiki/index.php/RTEMS_Tester is a support project
>> not directly in RTEMS. Most of the programming would be Python.
>
> You are right, a great chuck of the AIO calls have been implemented
> already (apart from aio_suspend(), for some reason). As for the RTEMS
> tester system, I have checked the wiki you've linked in the email but
> I'm not sure if I'd be fit for those projects. I'm not quite sure what
> the "Site and User Profile" project is about. Is it about realizing an
Site and User Profile would be about supporting specific deployments
that use RTEMS Tester to test their RTEMS projects, e.g. if they have
a rack of boards they can test with some custom networking or serial
ports, etc. I think this is too undefined at present.

> error checking application for configurations so the user is sure
> their configurations are right? The "Testing Database" project is
> pretty straightforward. I haven't worked with Python actively thus far
> and my last database class was 2 years ago so I'd have to do some
> additional learned of Python/SQL apart from doing the actual project.
You really would have to check with Chris Johns about this. I can
think of a handful of ways to improve the current RTEMS Tester, such
as adding support for more simulator-based BSPs, or adding the
coverage-testing [1,2] to the RTEMS Tester would be a really useful
contribution. Especially if you also add a build set for the
coverage-enabled simulator.

[1] http://wiki.rtems.org/wiki/index.php/RTEMS_Test_Coverage
[2] http://wiki.rtems.org/wiki/index.php/Code_Coverage_Status

> If the priority of either test projects is high I'll do that. But if
> somebody does care about TIPC I'll gladly port it to RTEMS. But once
> again that is if priority is not a matter and if somebody does care
> about TIPC.
>

Another idea is getting LWIP to work reliably and in a way we can
automatically test would probably be a worthwhile project.

You should start to work on getting the basic proposal/application
written so that you can add the 'meat' of your content when ready. you
can upload a proposal to melange and then update it later if you like.

> Kind regards,
> Janek van Oirschot