sdcard structure refactor

[zxkmm]

Temporary close to prevent wasting pipeline resources. If you are interested in following changes, check here https://github.com/zxkmm/mayhem-firmware/tree/sdcard_refactor thank you!

plan

• Separate system sdcard content and user sdcard content
• For those apps that calling fileman view to pick files (e.g playlist), let them freely jump between two.
• For those apps that read and appends into specific view (e.g freq man) then just append (combine) them together.

advantages

• it’s easier for user to update and control the files. And can clearly sort and manage their own files and official files.
• we can separately control the version of fw+apps along with SYS(aka official files), so user would not need to manually compare and merge them, if they have their own files

rough PoC

https://discord.com/channels/719669764804444213/724703536528621609/1215340288424284252

[NotherNgineer]

I like the idea of separating user and sys files, but I'd like some clarifications:

1. Would every file & folder in the downloadable SDCARD image be considered "SYS", so it's no problem to just delete the SYS folder and download a new one? Or will the SDCARD image contain some USR files/folders (e.g. empty directories and README files) that the user won't be expected to delete but will still need to MERGE?

2. Would the /USR folder contain much of the same subfolder structure, except with files that have been changed from the original downloaded SDCARD image?

2b. If a user opens a SYS/FREQMAN file and modifies it, I assume that the modified file (of the same name) will get saved in the USR/FREQMAN folder?

2c. Any issues having a file of the same name in both SYS and USR folders?

3. Will all of the automatically-created .ini files get placed in the USR/SETTINGS folder, and all of the automatically-created log files get placed in the USR/LOG folder, so they're not blown away if the SYS folder is deleted? (Or are you considering them to be SYS files?)

4. If the user downloads a new firmware image I presume that the recommendation will be to place it in the USR/FIRMWARE folder, and if the user downloads a bunch of SPLASH images I presume that they should be placed in a USR/SPLASH folder, so they don't get blown away if they delete the whole SYS folder?

4b. Therefore, will empty USR folders be part of the SDCARD image so the user will know where to put such files above (or will firmware automatically create these USR folders at power-up if they don't exist)?

5. Will root-directory files (splash.bmp, debug_log.txt, etc) be placed in the USR folder, or remain in the root folder?

6. Are we going to worry about the firmware upgrade/downgrade scenarios where files are no longer in the expected folders and suddenly the user's apps (ADSB-RX, etc) are no longer working after changing firmware version?

7. Is any noticeable delay added by apps having to navigate the additional subdirectory hierarchy, and to check multiple directories for files?

[zxkmm]

Thanks for asking!

Would every file & folder in the downloadable SDCARD image be considered "SYS", so it's no problem to just delete the SYS folder and download a new one? Or will the SDCARD image contain some USR files/folders (e.g. empty directories and README files) that the user won't be expected to delete but will still need to MERGE?

i think every file & folder in the downloadable SDCARD image be considered "SYS"

Would the /USR folder contain much of the same subfolder structure, except with files that have been changed from the original downloaded SDCARD image?

Basically yes, because as the video shows it's the concept that allow user to jump.

2b. If a user opens a SYS/FREQMAN file and modifies it, I assume that the modified file (of the same name) will get saved in the USR/FREQMAN folder?

I tend to say better still allow user to edit it but with a display modal warn. cuz if we separate them automatically, users would be confused.

2c. Any issues having a file of the same name in both SYS and USR folders?

In fileman picking view, it should be fine. in the freqman view, i'm not sure yet, cuz i haven't read that part.

Will all of the automatically-created .ini files get placed in the USR/SETTINGS folder, and all of the automatically-created log files get placed in the USR/LOG folder, so they're not blown away if the SYS folder is deleted? (Or are you considering them to be SYS files?)

i consider them as /USR, other ideas is welcomed.

If the user downloads a new firmware image I presume that the recommendation will be to place it in the USR/FIRMWARE folder, and if the user downloads a bunch of SPLASH images I presume that they should be placed in a USR/SPLASH folder, so they don't get blown away if they delete the whole SYS folder?

Ya i think they can put candidate images in /USR/SPLASH

4b. Therefore, will empty USR folders be part of the SDCARD image so the user will know where to put such files above (or will firmware automatically create these USR folders at power-up if they don't exist)?

I think empty folder can exist in release package, since most OS won't overwrite it even if user copypasta them. And if it's not existed, it will be created automatically, during apps launching, instead of during boot.

Will root-directory files (splash.bmp, debug_log.txt, etc) be placed in the USR folder, or remain in the root folder?

i consider them as USR, unless you have other ideas.

Are we going to worry about the firmware upgrade/downgrade scenarios where files are no longer in the expected folders and suddenly the user's apps (ADSB-RX, etc) are no longer working after changing firmware version?

Yes, it definitely not compatible with old versions. But i think there are no users will only update sdcard content without updating firmware?

Is any noticeable delay added by apps having to navigate the additional subdirectory hierarchy, and to check multiple directories for files?

I didn't see delay on my device.

[zxkmm]

Temporary close to prevent wasting pipeline resources. If you are interested in following changes, check here https://github.com/zxkmm/mayhem-firmware/tree/sdcard_refactor thank you!