Skip to content

FatFs setup

FatFs platform

Giving store-and-forward a file backend. FatFs covers what the adapter fills and what it leaves to you.

The shape

SolidSyslogBlockStore
        │
SolidSyslogFileBlockDevice     ◀── sequence-numbered <prefix><NN>.log files
        │
SolidSyslogFatFsFile           ◀── this adapter
        │
FatFs core                     ◀── vendor sources, you compile them
        │
your disk I/O driver           ◀── you write this

The adapter owns the middle box only. It never reaches the storage medium.

FatFs is configured by a header you own, so the adapter compiles inside your target against your configuration:

set(SOLIDSYSLOG_PLATFORMS "FatFs;<Network>;<OsPrimitives>")
target_link_libraries(my_app PRIVATE SolidSyslog SolidSyslog::FatFs)

This platform fills the File role only; the placeholders are whichever platforms the capability matrix says fill the rest of what your build needs. See naming your platforms for how the list is read.

What you must provide

The FatFs sources, compiled into your image, and a ffconf.h where the library expects to find it — beside the sources rather than on the include path, which differs from most configuration headers.

A disk I/O driver for your storage hardware, implementing the read, write and control entry points FatFs calls. This is the part that knows about your medium, and nothing in this library reaches past it.

A system layer if you have enabled re-entrancy, providing the synchronisation objects FatFs expects.

Mounting is yours. The adapter opens, reads and writes files; bringing the volume up belongs to your start-up code.

Durability

The adapter calls f_sync after every complete write. That writes back the cached data, updates the directory entry so the file's recorded size includes the record, and asks your driver to sync. The loss window is therefore one incomplete write rather than everything written since the file was last closed.

Whether the sync reaches the medium is your driver's CTRL_SYNC and the hardware beneath it: a driver that reports success without flushing a device cache narrows nothing.

FAT is not a journalling file system. A device that loses power partway through a directory update can leave that entry inconsistent, which is a property of the format rather than of this adapter. Where records must survive a hard power cut, size them and choose the store's discard policy with that in mind.

When it does not work

Failures report through the error handler rather than silently. Install one before you start, and read error severity for what each level is telling you — a CRITICAL at create time means the file fell back to the Null object, and nothing will be stored.