First serious RFS job - rfs bitmaps

Hi. Today entry is about bitmaps. RFS uses it to manage informations about blocks and inodes - are they free or not. This was my first task on RFS, fortunately there was big piece of test code on bitmaps written by  Chris Johns and I simply have to change it to fstest and extend it to cover rest of code.

My part of test contain check of set, clear and test map's bit when specified bit number is larger than map size. Another thing was use of rtems_rfs_bitmap_map_set_all function and then clear and set random bit. I have also to  attempt to find clear bit when all bits were set. I also invoke rtems_rfs_bitmap_map_clear_all directive.

In many functions there were branches which can execute probably only when pointer to bitmap control structure function was invalid, so I had to invoke all bitmap related directive with null pointer and check if return value is appropriate.

There were also another tricky and hard to execute branch in bitmap open directive. This branch could execute only when there would be lack of memory - it returned ENOMEM. It takes me a lot of time and I need help from my mentor - dr Joel Sherrill. He adviced me to use rtems_heap_greedy_allocate directive which cause allocation of almost all heap. You can specify how much blocks should be left on heap. I used this directive and it eventually helps. Attempt to open bitmap returned ENOMEM :)

All bitmaps code is covered. I think this is quite big success :) And my next battlefield will be block maps - which make use of bitmaps.

RFS bitmap test code is here.

fpathconf() test

As promised in last post, this entry is about fpathconf test. This is first test I was working on in range of developmental part of coverage. My mentor, Dr. Joel Sherril suggested me to take this function to cover first - as it should be quite simple to cover it. So I started my research. It gives not only full coverage of fpathconf but also discover some lacks in covoar - coverage tool in RTEMS coverage analysis.

RFS - my new battlefield

After long period of silence I am writing this post to summarize my last weeks efforts on RTEMS coverage.

Because coverage in core profile is near 100%, I and my mentor decided to start work on developmental parts of RTEMS. I looked on analysis results and tried to find out where are the largest uncovered ranges. My choice was RFS.

RFS is acronym of RTEMS File System. Some informations about this are here. Base filesystem in RTEMS is IMFS  = in memory file system. Other filesystems can be mounted in IMFS.

First of all I had learned how to mount filesystem and how to register RAM disk. This takes me a lot, I tried to understand everything, but there was still some errors and failures. Fortunately, this part of work on coverage of filesystems is done and you don't have to struggle with registering RAM and mounting filesystem on your own.

In directory rtems/testsuites/fstests there are set of tests of filesystems. There are also some support files, which allow you to focus on your unexecuted ranges and don't pay attention to rest. In directory rtems/testsuites/fstests/support there are files responsible for registration of RAM disk,  configuration of RTEMS, initialize file system. In directories named like FILESYSTEM_support (mrfs_support, imfs_support, mdosfs_support, etc.) are files related to specific file system. Thanks to these support files you have only write your test() function.

This approach allow to reuse test() in different file systems. You simply have to make directory mrfs_TESTNAME - for mounted RFS, mdosfs_TESTNAME - for mounted DOS file system, etc. and write makefile which takes appropriate support files. There are lot of tests in fstests and you can follow it to make your own filesystem test.

My next post would be about test on fpathconf() which also show some lacks in coverage tools. But it is another story :)