Changes between Version 23 and Version 24 of SOCIS/2016

Timestamp:

10/30/16 10:49:15 (7 years ago)

Author:

Saeed Ehteshamifar

Comment:

--

SOCIS/2016

@@ -57 +57 @@
 * 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.
+* 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.