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, наб
signature.asc
Description: PGP signature
