Project Goal

The goal was to replace DOSFS with a lighter FAT implementation and provide benchmarking – This was done by porting the open‑source FatFS file‑system to RTEMS. This would offer a smaller, simpler alternative to RTEMS’s custom DOSFS and reduce memory usage while maintaining functionality. The proposal also called for building integrated benchmarking tools to measure performance of different file‑system implementations.

Work Done

All of the code and tests I’ve wrote are available in this MR: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/694

Also, this is the epic with my progress report: https://gitlab.rtems.org/groups/rtems/-/epics/25

Here’s a summary of what I accomplished during GSoC:

• Integrating FatFS into RTEMS – I imported the upstream FatFS code into the RTEMS source tree and began implementing diskio.c to connect FatFS’s disk I/O layer to RTEMS’s libblock.

• Mounting and basic file operations – By mid‑term, FatFS could be mounted and recognised as a valid file system. I created mount/initialisation functions and taught libio to register FatFS volumes, allowing the existing fileio sample to mount FatFS instead of DOSFS. I’ve also implemented Disk I/O handlers (disk_initialize, disk_read, disk_ioctl etc.).

• Expanding coverage to directory and file operations – I’ve added numerous handlers to make FatFS compatible with RTEMS’s file, directory and path evaluation operations. I’ve also wrote/adapted tests; fixed issues such as ls returning garbage characters or failing to handle trailing slashes.

• POSIX‑compliance and bug‑fixing – Over the final weeks, I systematically ran RTEMS’s filesystem test suite against the FatFS integration and fixed issues uncovered. Key fixes included handling O_TRUNC properly, updating file/parent directory timestamps on writes and truncations, implementing utime() and statvfs(), mapping FatFS error codes to correct POSIX errno values, enabling large‑volume formatting (FM_ANY vs FM_FAT), and addressing lseek overflow semantics.

Future work

• Benchmark integration and performance evaluation – The project proposal included extending previous benchmarking tools for filesystem comparison. It would be a good next step to do this, and have a comparison between FatFS and other filesystems (specially DOSFS), from performance and memory footprint perspective.
• Code review and upstream merge – After some final touches, we need to open MR, get reviews, and merge the code into RTEMS for the users to actually use this new filesystem 🙂

Challenges & Lessons Learned

• Understanding RTEMS filesystem internals – Porting FatFS required mapping RTEMS’s filesystem operations to FatFS primitives. I learned about libblock, libio and rtems_filesystem_operations_table and how to integrate a new filesystem into RTEMS.

• Aligning FatFS behaviour with POSIX expectations – FatFS is designed for embedded systems and differs from POSIX in areas like timestamp handling and fsync semantics. I had to implement wrapper code to align with POSIX requirements and RTEMS conventions (e.g., fsync being called automatically at f_close).

• Debugging complex bugs – Issues such as double‑free corruption, inconsistent directory semantics, incorrect error code mappings, lseek overflow behaviour and large‑volume formatting required detailed debugging and test‑driven development. I learned a lot during hunting them down and fixing them!

Final Thoughts

I’m grateful to the RTEMS community for their support throughout this project, especially my mentors Chris and Gedare for their guidance, and Andrei for helping me get started with embedded systems. This has been a rewarding experience, and I’ve enjoyed both the challenges and the chance to contribute to the community.