Hi!
I'm preparing to replace src:fuse-umfuse-fat with
https://github.com/virtualsquare/fusefatfs,
which "has been developed as a replacement for fusefat"
(the previous upstream, same vendor, not really relevant),
and "is based on the FAT file system module for embedded systems
named fatfs by ChaN".
This is http://elm-chan.org/fsw/ff/.
A DCS query for "FatFs - Generic FAT Filesystem Module" yields
* micropython
* swupdate
* tinyusb
* dolphin-emu
Actually, micropython's one is a fork:
/* This file is part of ooFatFs, a customised version of FatFs
* See https://github.com/micropython/oofatfs for details
*/
leaving us with
swupdate R0.14a
dolphin-emu R0.14b
tinyusb R0.15 w/patch1
fusefatfs R0.15 w/patch1
Per changelog in http://elm-chan.org/fsw/ff/updates.html,
R0.14[ab] are compatible, just bugfixes (as expected).
R0.15 is not, and needs a migration.
It's impossible to build a libfatfs.so,
because it's heavily build-time-configured (ffconf.h);
all surveyed programs deviate from the provided config.
The config header is strongly versioned against ff.h
(and ff.c) and errors out if it's mismatched.
The config changes a little bit between R0.14a and R0.14b
(but trivially, and to an extent that can be easily patched downstream
by diff -u ff14a/source/ffconf.h ffconf.h > d
cp ff14b/source/ffconf.h .
patch -p1 < d
and putting the result in d/patches).
The config changes significantly between R0.14* and R0.15
(as expected for a migration-needing version anyway).
dolphin-emu further patches its fatfs by:
s/TCHAR/FATFS_TCHAR/g
s/_T\(EXT\)?(/FATFS_&/ (these macros aren't actually used by dolphin,
but they are fatfs API)
applying
- if (((BYTE)c & 0xF1) == 0xF0) pb->ct = 3; /* 4-byte sequence? */
+ if (((BYTE)c & 0xF8) == 0xF0) pb->ct = 3; /* 4-byte sequence? */
which is a bugfix also included in fatfs 0.15
swupdate adds some licence comments, but nothing material.
I started writing this to propose some sort of hoisting,
but this no longer appears feasible. Ah well.
Best,
наб
Attachment:
signature.asc
Description: PGP signature