■ 1. 概要
- UTFS（micro TAR File System）は、CLI Systemsが開発した組み込みシステム向けの軽量ファイルシステム構造
- フラットアドレス空間の記憶媒体上で、文字列ベースのファイル名によるデータ管理を実現する
- データの格納詳細をアプリケーション層のデータ構造から分離し、データサイズや位置の変更をデータ損失なく行える
- 読み取り・更新・書き込み操作を主目的とし、ストリーミングや追記操作は限定的にしか対応しない
■ 2. 従来手法の問題点
- アプリケーションロジックとデータ構造の密結合:
- データ構造をグローバルな extern 変数として共有するため、すべてのサブシステムが同一構造体に依存する
- 構造体を変更するとインクルードしている全ソースが再コンパイルされる
- 無関係なコードによるデータ改ざんリスク:
- バッファオーバーフローが構造体の隣接メンバを破壊する（例：8バイトのシリアル番号フィールドに12バイトを書き込むと、隣接する subsystem1_settings が上書きされる）
- 原因箇所と影響箇所が離れているため、デバッグが困難になる
- 構造の硬直性:
- フィールドサイズの変更時に旧フィールドが未使用領域として残存する
- 後から追加されたフィールドが既存フィールドの間に混在し、構造が断片化する
- 変数名の硬直性:
- グローバル変数やメンバ変数のリネームがファームウェア全体に波及する
■ 3. UTFSによる解決策
- 1970年代のテープドライブ向けTARファイルフォーマットの概念を採用:
- TARはフラットアドレス空間のストレージに複数ファイルを格納するための形式
- ヘッダとデータブロックを順次配置する方式
- TARの基本概念にメモリブロックへのポインタを組み合わせ、ソースコード実装から独立した任意データの格納・取得を実現する
- 各サブシステムが独自のローカルデータ構造を持ち、相互に影響しない
■ 4. UTFSの固有の特性
- open/closeパラダイムを採用しない:
- モダンなファイルシステムのopen/closeはストリーミング・追記操作向けであり、load-modify-saveパラダイムと整合しない
- すべてのデータはRAMにロードするかRAMから保存する
- 小型ヘッダ設計:
- TARの512バイトヘッダに対し、UTFSは24バイトヘッダを採用
- ファイル名は最大11バイト（＋NULLターミネータ）の12バイト領域に格納
- 16ビットのシグネチャ変数をヘッダに内蔵:
- バージョン管理やデータ検証に利用できる
- データとともに自動的に保存・読み込みされる
■ 5. インタフェース
- 主要API:
utfs_set(): ファイル名とRAMデータポインタおよびサイズを関連付けるutfs_register(): ファイルをUTFSに登録するutfs_load(): ストレージから全データをRAMにロードするutfs_save(): RAM上の全データをストレージに保存する- 各サブシステムは個別のヘッダインクルードと構造体定義・登録処理を持ち、他のサブシステムから独立する
■ 6. データサイズ変更への対応
- RAM構造体がストレージ上のファイルより小さい場合: RAM構造体のサイズ分のみロードし、オーバーフローを防止する
- RAM構造体がストレージ上のファイルより大きい場合: ストレージ上のサイズ分のみロードする
utfs_save()実行時は現在のRAM構造体サイズで書き込まれ、全データが自動的に再配置される（データ損失なし）■ 7. ベストプラクティス
- シグネチャ変数によるデータバージョン管理:
uint16_t型のシグネチャ値でロードされたデータのバージョンを判別する- 旧バージョンのデータを新バージョンに移行する処理を実装できる
- シグネチャは「バージョン」に限らず、データチェックサムなどの用途にも使用可能
■ 8. 既存データストレージとの統合
- UTFSデータの「ベースアドレス」を設定する機能を提供する
- 既存のレガシーデータ領域と重複しないアドレスにUTFSを配置することで、フィールド稼働中のファームウェアにも段階的に導入できる
■ 9. まとめ
- UTFSは不揮発性ストレージとRAM間のデータ管理をシンプルかつ低オーバーヘッドで実現する
- データ格納構造をアプリケーションコードから分離し、新規・既存システムの両方に統合可能
- MITライセンスでGitHub（https://github.com/clisystems/utfs/）にて公開されている