Should we be using filesystem.c or LFS directly? #91
-
|
Is filesystem.c supposed to be a proper abstraction over LFS, or is it just a set of helper functions? I want to not read a whole file at a time in movement (TOTP filesystem support), and want to know if it's better to use LFS directly in a watch face or add something to filesystem.c. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
It's definitely mostly a set of helper functions; this is some code that was on a branch for a very long time with the hope of writing more robust filesystem functionality, but then merged in just to have something there rather than nothing. Everything up through line 50 is the underlying support functions that get LFS working with the EEPROM emulation area in the microcontroller; in all likelihood that should move out to the watch library. As for the rest, I would say for now you should interact directly with LFS (it should work on the simulator too) and trust that whatever we come up with for file management will be more robust than the stuff in filesystem.c |
Beta Was this translation helpful? Give feedback.
It's definitely mostly a set of helper functions; this is some code that was on a branch for a very long time with the hope of writing more robust filesystem functionality, but then merged in just to have something there rather than nothing.
Everything up through line 50 is the underlying support functions that get LFS working with the EEPROM emulation area in the microcontroller; in all likelihood that should move out to the watch library. As for the rest, I would say for now you should interact directly with LFS (it should work on the simulator too) and trust that whatever we come up with for file management will be more robust than the stuff in filesystem.c