Refactor out staticDIR

[stellar-aria]

Removes global staticDIR in favor of local FatFS::Directory instances

[github-actions]

Test Results

106 tests  ±0   106 ✅ ±0   0s ⏱️ ±0s
 16 suites ±0     0 💤 ±0 
 16 files   ±0     0 ❌ ±0 

Results for commit c3b082f. ± Comparison against base commit 547b62b.

[m-m-adams]

I think we also need to configure fatfs as re entrant to do this safely, this change means multiple different dirs can be held but fatfs still can't access anything other than the last one it opened. To do that I think we need mutex support (and blocking) as well

[jamiefaye]

The reason we have staticDIR is because iterating through a large directory is quite slow. Since there is a limit on how many directory entries can go into a SysEx reply, we limit each request to a small number of line items. If we iterated from the beginning to get to the subrange requested each time, it really does get slow. So I came up with a cache scheme.

[stellar-aria]

I think we also need to configure fatfs as re entrant to do this safely, this change means multiple different dirs can be held but fatfs still can't access anything other than the last one it opened. To do that I think we need mutex support (and blocking) as well.

@m-m-adams Looks like FatFS needs to be provided some stuff: ff_mutex_take, ff_mutex_give, ff_mutex_create and ff_mutex_delete.

The reason we have staticDIR is because iterating through a large directory is quite slow. Since there is a limit on how many directory entries can go into a SysEx reply, we limit each request to a small number of line items. If we iterated from the beginning to get to the subrange requested each time, it really does get slow. So I came up with a cache scheme.

@jamiefaye What do you mean? Git blame for staticDIR and staticFNO point to Rohan's original commit to the codebase. And staticDIR is never used in a function that doesn't call f_opendir() first, so it's never used contextually without a relevant creation the way that I would expect piecemeal loading works

[stellar-aria]

@jamiefaye if you're referring to sxDIR in

DelugeFirmware/src/deluge/storage/smsysex.cpp

Line 26 in d4dda68

DIR sxDIR;

this PR does not touch that

[jamiefaye]

I am wrong about the staticDIR. The DIR iteration caching stuff is over in smsysex.cpp. – Jamie

…

On Sat, Dec 28, 2024 at 2:12 PM Katherine Whitlock ***@***.***> wrote: I think we also need to configure fatfs as re entrant to do this safely, this change means multiple different dirs can be held but fatfs still can't access anything other than the last one it opened. To do that I think we need mutex support (and blocking) as well. @m-m-adams <https://github.com/m-m-adams> Looks like FatFS needs to be provided some stuff: ff_mutex_take, ff_mutex_give, ff_mutex_create and ff_mutex_delete. The reason we have staticDIR is because iterating through a large directory is quite slow. Since there is a limit on how many directory entries can go into a SysEx reply, we limit each request to a small number of line items. If we iterated from the beginning to get to the subrange requested each time, it really does get slow. So I came up with a cache scheme. @jamiefaye <https://github.com/jamiefaye> What do you mean? Git blame for staticDIR and staticFNO point to Rohan's original commit to the codebase. And staticDIR is never used in a function that doesn't call f_opendir() first, so it's never used contextually without a relevant creation the way that I would expect piecemeal loading works — Reply to this email directly, view it on GitHub <#3162 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACDOGKRHABLGTUVP35QIEDT2H4A4HAVCNFSM6AAAAABUHRNVASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUGQZDMNRWGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>