= European Space Agency Summer of Code in Space 2016 =

[[TOC(SOCIS/2016, depth=2)]]

This page captures the students who make proposals as well as those who work on projects for RTEMS as part of ESA SOCIS 2016.


= Students' Proposals =

Start filling in this table for yourself as soon as possible and update as needed.

|| '''Student''' || '''Completed Hello''' || '''IRC Handle''' || '''Proposal Title''' || '''Google Docs URL''' 
||NAME || Yes or No || nick on #rtems || Project Title  || Link to Google Docs for proposal (shared with mentors) 
|| Saeed Ehteshamifar || Yes || salpha || RTEMS Fault tolerance: Get a fault injection tool to work with RTEMS (continuation from [https://devel.rtems.org/wiki/SOCIS/2015 last year]) || [https://docs.google.com/document/d/14hNEIi-FaywfvpB71yll-3FvzgbhUS2nhiiWZ8V7s7A/edit?usp=sharing Proposal]

The columns are to be filled in as follows:
* The ''Student'' column is for your name. 
* The ''Completed Hello'' column lets us all know whether or not you completed the require Hello World project. Based upon our experience, students who have successfully compiled and run an RTEMS application have a MUCH MUCH higher chance of success on the proposed project.
* The ''IRC Handle'' column is your handle on IRC.  RTEMS folks hang out in #rtems on freenode.net.
* The ''Proposal Title'' should be self-explanatory.
* The ''Google Docs URL'' is your proposal in Google Docs that can be reviewed and commented on by mentors. The [https://docs.google.com/document/d/1F5XCodvX8AYNqWX5ssu7dfjkmFT__83uf8ABKbB_Pkg/edit?usp=sharing proposal template] should be '''copied''' and used as a baseline. This can be shared with mentors for review. Mentors can insert comments for you. 

'''WARNING''': The Google Docs version of the proposal is a '''WORKING''' copy. You '''MUST''' submit the official and final proposal using the ESA SOCIS site. If you do not submit the final proposal via the ESA SOCIS site, you cannot be considered

= Students' Summer of Code Tracking Table =

Students whose GSoC project is accepted by RTEMS shall fill in a slot with their information in the following table, which helps to centralize [wiki:Developer/GSoC/ProjectManagement  SoC Project Management].
||'''Student''' || '''IRC Handle''' || '''Project Link''' || '''Repository Link''' || '''Blog'''
||NAME || nick on #rtems || Link to Project Wiki page  || Link to project's public Github repository || Link to your development blog
|| Saeed Ehteshamifar || salpha || [https://devel.rtems.org/wiki/SOCIS/2015/FaultTolerance Wiki] || [https://github.com/salpha2004/slingshot slingshot] || [http://rtems-fi.blogspot.de/ Blog]
The columns are to be filled in as follows:
* The ''Student'' column is for your name. 
* The ''IRC Handle'' column is your handle on IRC.  RTEMS folks hang out in #rtems on freenode.net.
* The ''Project Link'' is a link to the Wiki page for your project.
* The ''Repository Link'' is a link to the github repository for your project.
* The ''Blog'' is a link to your blog with entries about your project. It should be updated regularly during the summer.

= Student Status Updates =
Each student has a section below for putting in notes from the weekly IRC meetings.

== Saeed ==
* May 27: Added the Status Updates page and added the link to my proposal.
* Jun 08: Got up-to-date with latest project's status. Republished slingshot as a stand-alone repository. Updated the Github repository and build instructions. Going to start integrating GRINDER's function (test suite execution and storing results) into slingshot.
* Jun 15: Prepared RTEMS development environment. Tried to redirect pc386's output to console (didn't work), used SPARC architecture instead. Thought about how to handle test case crash scenario. Updated the blog.
* Jun 22: Off due to exams preparation.
* Jun 29: Off due to exams preparation.
* Jul 06: Prepared and tested Vagrant scripts to setup/build rtems and setup/build slingshot. Started changing test suite template to include a label that is moved to the next test case whenever a test case crashes.
* Jul 13: Added parsing output of test cases execution. Added support to tolerate crashes of test cases by proceeding to the next test case and re-making the test suite. This method is NOT scalable since it involves re-making the test suite. Going to execute test cases dynamically via RTEMS libdl to cope with this issue. 
* Jul 20: Updated the blog. Executed a test suite with more than 600 test cases to test the slingshot's function in auto-skipping crashed test cases and also find out some faults that lead to failures. Read RTEMS 4.5.0 Evaluation Report (by Critical Software) to see how they cope with crash and also have a basis to compare slingshot with. Going to update Vagrant scripts, build instructions, change the test suite template, and modify slingshot to dynamically run test cases.
* Jul 27: Updated build instructions to re-produce the work via Vagrant. Tried to use libdl01 example in test suites to make a dynamically linked (DL) application (not fruitful). Going to follow community's instructions to build it.
* Aug 03: Tried Chris John's instructions to build a DL app via WAF build system (didn't work). Tried Pavel Pisa's instructions to build it via OMK build system (worked). Going to change the test executor to TAR all test cases and dynamically load and execute them at run-time.
* Aug 10: Ran Pavel Pisa's appdl (sample dynamically loaded app) with his help. Wrote a DL app, with OMK to make it (worked). Manually changed test case executor to see if everything works. Going to establish a TCP connection in test case executor between RTEMS and QEMU to pass test cases names. Then changing slingshot accordingly.
* Aug 17: Wrapped up achievements about dynamic linking: updated the blog, the wiki, and the repository with a sample DL app. Tried to build the test suite via OMK, faced an error, posted a question to the mailing list. Tried to make a network app, both network-demos and my app didn't work. Going to fix these issues and finalize the test suite template (testcase executor). 
* Aug 24: Resolved the issue of compiling C++ files via OMK with Pavel Pisa's help (changing the extension to .cc). Manually changed the test suite template to dynamically load test cases. Fixed a configuration issue of the test suite (CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS). The new problem is to combine test case object file and test setting object file into one file to dynamically load it and call the test function.
* Aug 31: Used 'ld -r' to combine test case object and test case setting file into one object file (Pavel Pisa's suggestion). Fixed the "symbol not found" issue while calling test cases by porting the test suite and test case template to C. Progressed in writing a sample DL app via WAF and updated the blog accordingly. Faced an "unresolved externals" error and posted the question to the ML. Going to continue with WAF for integration of the process to slingshot and also add a TCP link between the test suite and slingshot to pass the test case name to run it.
* Sep 07: Tried to make a simple network app. Faced several issues. Going to debug them and report if they're RTEMS bugs.
* Sep 14: Struggled more with writing a network app. Posted a question to the ML on how to use the new TCP/IP stack. Started merging changes back to Slingshot: porting the template to C, using OMK Makefile, using dynamic linking to run test cases.
* Sep 21: No luck in using networking with the new TCP/IP stack. Tried passing args to Init task via sparc-rtems-run (didn't work). Pavel Pisa sent a patch to make if_fxp work hence reverted to the old TCP/IP stack (it worked with Qemu). Going to change Slingshot's test case generation and execution process.
* Sep 28: After Gedare Bloom's suggestion on using serial console for passing test case name, going to change Slingshot accordingly. Will update the repository with the final version (dynamic linking assisted execution), write a future work document, and update the blog with the big picture about the dynamic linking assisted execution until Oct 15. End of SOCIS 2016.

= Final Reports (brief) =

== Saeed Ehteshamifar: RTEMS Fault Tolerance ==

This year's project was continuation of RTEMS Fault Tolerance project from [https://devel.rtems.org/wiki/SOCIS/2015#SaeedEhteshamifar:RTEMSFaulttolerance the last year]. According to the [https://docs.google.com/document/d/1DVbwDUEf0DDzzLQbYQo7oPF0zKwueCaLS87cqKSlsGw/pub#h.yd5gsvhyhgpg last year's future works], the following task were proposed for this year:
1. Distributing Slingshot as a stand-alone repository, instead of a patch to the original version.
2. Integrating GRINDER's functionality (running tests and storing the result) into Slingshot in order to decrease the maintenance costs.
3. Automatically continuing the test execution process in case a test case crashes.
4. Dynamically linking and loading test cases to the test executor, in order to decrease code complexity and overall run time.
5. Gathering statistics and reporting the results in an easy-to-read and human-friendly way.

The four first items from the list above were implemented. In addition,
1. Slingshot's development environment was migrated from the deprecated [https://github.com/utahta/pythonbrew Pythonbrew] to [https://github.com/yyuu/pyenv pyenv], and
2. [https://www.vagrantup.com/ Vagrant] scripts were written to facilitate reproducing the work.

Further future works are elaborated as follows:
1. Gathering statistics and reporting the results in an easy-to-read and human-friendly way.
Initially [https://www.r-project.org/ R] was proposed for this matter but this can be changed based on the contributor’s discretion because nothing has been done in this respect.
2. Permuting the order of test cases and repeating the test to decrease the dependence impact.
The dependence impact is the impact that each test case might have on the test cases that run afterwards due to the changes in the system state, i.e. memory, IO, registers, etc. For example, consider two consecutive test cases for function ''free''. If due to a bad implementation of free by the OS, the first one passes but leaves the system with an inconsistent memory state (huge leak, etc.) that leads to the failure of the second test case, this is a dependence impact. Because by itself, the second test case might be non-faulty. However due to the dependence impact, it seems that it is faulty.
In order to minimize this impact, the order of executing the test cases should be randomly permuted and any difference in the results should be carefully analyzed.
3. Covering and testing POSIX as far as implemented by RTEMS. That is, generating a more complete test case list (via ''util'' folder scripts) and running the test process (executing, permuting, storing) for it.
4. Extending to the classic API.
Even if all POSIX functions are tested, many RTEMS users use RTEMS Classic API for application development. Therefore it is crucial to extend the test to the classic API as well. However, this might be a little tricky since Slingshot’s code generation module is based on Ballista, which has originally targeted POSIX API. This means function signatures, definition of compound data types in the type hierarchy, and maybe some other basic elements are specific to POSIX and should be tailored to the classic API to add support for this API.
5. Using RTEMS Source Builder to facilitate invoking the test process and merging with the RTEMS code base.