Status: Tests for IMFS exist. No work on making them general has been done.
RTEMS supports multiple file systems including the In Memory File System, a DOS FAT file system, and the RTEMS File System (RFS). We would like to have high test coverage on all of the various file systems that exist today and might be added in the future. Since all of the file systems are accessed from user applications via POSIX system calls, using them is similar. Thus we should be able to have a core set of tests that can be built to use a RAM disk and various file systems.
Currently RTEMS has a body of tests that provide high coverage for the IMFS but not the FAT filesystem or RFS. The RFS has test scripts which exercise it but no coverage analysis.
The goal of this project is to add a new test suite to RTEMS which will be able to use the same tests on different file systems. The initial set of file systems included is:
- IMFS as mounted file system
- IMFS as root file system
- FAT as mounted file system
- RFS as mounted file system
This means that individual tests will have to accommodate different base directories for testing.
I envision something like this:
- fsXX test directory with test code
- fs_FSTYPE_01 will have Makefile.am to build source from fsXX plus support/FSTYPE
In this manner, a set of "fsXX" tests can be instantiated for each file system implementation.
In order to be able to run on ALL possible BSPs we can not rely on having non-volatile storage. So the tests will have to allocate RAM for a RAM disk, format it as a specific file system, and mount it. This support code will be file system type specific and will be invoked before the file test code.
The file system test will be integrated in the RTEMS source tree and coverage measurements will be made using it.
One challenge is limitations in file system capabilities. Certain tests will need to be able to push the limits of a file system or exercise specific paths. We envision that most of a file system's code can be covered with shared test cases. Other cases may have to be developed that are specific to a file system. Similarly, the test code may have to adapt to differences like file naming restrictions or permissions.
The ultimate goal is 100% instruction and branch coverage for all file systems.
The developer tackling this project will need to be able to write RTEMS test code which effectively are multiple small applications. They will have to be able to read file system code and be able to read it enough to test it and make suggestions where needed.
A GNU/Linux environment RTEMS development environment with a simulator such as Qemu is sufficient for this project. It is possible that the entire project could be done with sparc/sis which doesn't have coverage reporting. In this case, the developer would be relying on the RTEMS team to provide coverage measurements as tests are submitted incrementally.
Whether the developer has a simulator with coverage capability, tests should be submitted incrementally.
- Chris Johns can provide simple examples of using the FAT and RFS file systems with a RAM disk
- Joel Sherrill can provide guidance on which existing file systems tests to rework into this suite.
- Not Yet
As the project progresses, you will need to add build instructions, etc and this page will evolve from a project description into a HOWTO.
If you have more to say about the project that doesn't fit in the proposed sections of this template, feel free to add other sections at will.