Changes between Version 5 and Version 6 of GSoC/2017/RTEMSTesterImprovements


Ignore:
Timestamp:
May 24, 2017, 8:11:36 AM (2 years ago)
Author:
Tanu Hari Dixit
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2017/RTEMSTesterImprovements

    v5 v6  
    1515
    1616* As of now, the configuration file format is a simple text file (with .mc extension) that serves to provide all the needed macros. This is really cryptic and needs to be converted to a suitable configuration format. I believe if I could add support for configuration files in YAML format, which will make it more readable, it would come really handy for developers to understand and tune them to their needs.
    17 * Also, sometimes a BSP configuration needs some user-specific data to function as expected. For example, look at this[3] macro file. Here, the path to the first stage bootloader (fsbl) has to be provided that is placed somewhere in the host machine. For this there should be proper control provided to the user as opposed to the hard coded configuration that is presently the case. This will help in the tunability of the configuration files.
     17* Also, sometimes a BSP configuration needs some user-specific data to function as expected. For example, look at this[https://git.rtems.org/rtems-tools/tree/tester/rtems/testing/bsps/xilinx_zynq_zc706.mc#n59 1] macro file. Here, the path to the first stage bootloader (fsbl) has to be provided that is placed somewhere in the host machine. For this there should be proper control provided to the user as opposed to the hard coded configuration that is presently the case. This will help in the tunability of the configuration files.
    1818* Currently, the tests that are expected to fail, the results of which are indeterminate and those which timeout because they expect input from user, all are counted as failed (or timeouts in the last case). This masks the actual reasons why a certain test failed (or timed out) and eventuate into test statistics that can be easily misunderstood. Therefore, one objective of the project is to add support for test states “expected-fail”, “indeterminate” and “user-input”, so that they can be tracked separately.
    1919* Furthermore, regression analysis is another objective of the project. Adding YAML files for each bsp that contain an expected statistic for the tests, shall help the cause. Hence, this statistic can be compared with the current number of failed tests and help determine if the BSP has regressed against a change in rtems (or the test results in RTEMS need updating.)