You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: spool records to a file store with a CRC-16 at rest
A SolidSyslogBlockStore over a FileBlockDevice over the library's FatFs port,
replacing the Null store. The service task drains the ring into the store and
sends from there, so a failed send costs a retry rather than the record: the
audit trail survives an outage instead of ending at it.
Flash +11,584 B (+3,956 on the previous stage)
RAM +9,128 B (+1,436)
Log stack +672 B (unchanged)
Service +960 B (+64)
The log stack does not move: storing happens on the service task, and a task that
calls Log still knows nothing about what happens after it returns. The service
task's own high-water rises 64 bytes, which its existing allocation absorbs.
The static RAM is pool allocation, not buffers. The block size is file capacity —
nothing holds a block in memory, so the store costs its handles rather than its
capacity.
CRC-16 detects corruption, not tampering: it catches a truncated write or bit-rot,
and anyone who can edit a stored record can recompute it. It establishes that a
record came back the way it went in, which is the prerequisite for spooling at
all. Making stored records tamper-evident, and then unreadable, are later stages.
Three decisions come with the store — capacity, what happens when it fills, and
whether to be warned before that point. This device stores four blocks, one file
per block, syslog00.log upward on the volume it already mounts, and discards the
oldest when full.
SolidSyslog::FatFs is a header-configured upstream, so it is named in
SOLIDSYSLOG_PLATFORMS and linked.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments