If you’ve worked with RTEMS, you’re probably familiar with its DOSFS — a serviceable FAT implementation that’s grown over time. But what if we could swap it out with something smaller, simpler, and easier to maintain? That’s exactly what this GSoC 2025 project aims to explore: porting FatFS, a lean and widely-used FAT/exFAT implementation, into RTEMS and building benchmarking tools to evaluate its real-world performance.

In this post, I’ll walk through the architectural plan for this port, share the feature compatibility insights (FAT12/16/32, LFN, Unicode, case folding), and describe the challenges and design strategies in porting FatFS into a modern RTEMS environment.

Why FatFS?
FatFS is a highly portable, memory-conscious filesystem library supporting FAT12, FAT16, and FAT32 — perfect for embedded systems. Unlike the more complex DOSFS in RTEMS, FatFS offers a minimal codebase, modular configuration, and great documentation, making it an attractive candidate for integration.

The goal isn’t just a replacement — it’s an upgrade in simplicity and maintainability, with robust performance measurement tools built-in.

Bridging the Gap: Mapping FatFS to RTEMS
Porting FatFS involves aligning its API with RTEMS’s filesystem infrastructure. RTEMS uses the libio and libblock subsystems to expose filesystem operations and access block devices, respectively. Here’s the plan to bring these together:

• Filesystem Registration: Implement rtems_filesystem_operations_table and related structures so that FatFS can register as a valid filesystem type.
• Mount/Unmount Logic: Use f_mount() and f_unmount() to interface with FatFS’s virtual volume logic, backed by RTEMS’s block device abstraction.
• File/Dir Handlers: Provide implementations for file and directory handlers (open, read, write, opendir, readdir, etc.) by wrapping FatFS calls.

Implementing diskio.c: RTEMS <-> FatFS I/O Bridge
The heart of the port is the diskio.c layer — a bridge that connects FatFS’s calls (like disk_read, disk_write) to the underlying RTEMS block driver API.

Example mapping:

DRESULT disk_read(BYTE pdrv, BYTE* buff, LBA_t sector, UINT count) {
    // Convert to RTEMS block device API (via bdbuf or direct I/O ops)
}

We’ll use rtems_bdbuf_read() and rtems_bdbuf_write() to handle sector operations, ensuring caching and sync behavior match FatFS expectations. Timestamp functions (get_fattime) will tie into RTEMS’s time services.

Feature Compatibility Overview
Let’s evaluate FatFS features based on your proposal’s criteria:

Feature	Support in FatFS	RTEMS Integration Notes
FAT12/16/32	✅ Yes	Select via config (ffconf.h). All formats supported.
Long File Names	✅ Optional	Enable _USE_LFN > 0. Requires dynamic memory or static buffers.
Unicode (UTF-16)	✅ Optional	Enable _LFN_UNICODE. Careful memory handling needed for RTEMS.
Case Folding	✅ Built-in	FATFS matches FAT behavior (case-insensitive by default).

We’ll ensure all these configurations are documented, tested, and enabled based on the use-case demands of embedded applications.