The IDF-provided VFS resolves several issues:
- The IDF components having a different view of the (virtual) file system
compared to the Lua environment.
- RTOS task/thread safety. Our legacy VFS was only ever safe to use
from the LVM thread, which limited its usability. Upgrading it
would have effectively required a reimplementation of the IDF VFS,
which would have been a bigger task with larger on-going maintenance
issues.
- We're no longer needing to maintain our own SPIFFS component.
- We're no longer needing to maintain our own FATFS component.
- The legacy of the 8266's lack of standard C interface to the file system
is no longer holding us back, meaning that we can use the standard
Lua `io` module rather than the cobbled-together swiss army knife
also known as the file module.
Of course, the downside is that we'll either have to declare a backwards
breakage in regard to the file module, or provide a Lua shim for the old
functions, where applicable.
Also included is some necessary integer type fixups in unrelated code,
which apparently had depended on some non-standard types in either the
SPIFFS or FATFS headers.
A memory leak issue in the sdmmc module was also found and fixed while
said module got switched over to the Espressif VFS.
Module documentation has been updated to match the new reality (and I
discovered in some places it wasn't even matching the old reality).
With the recent flash layout changes, it became very possible to misdetect the
flash size. We're now using the partition table as the guard marker, since
that really shouldn't be all 0xff. Also, we now don't clobber the flash
device id (and keep block/sector/page/mask values).
Johny Mattsson
Johny Mattsson