How to correctly separate volume manager from file handles

[nsallis]

I keep running into this issue where I want to refactor to have a function like get_file_handle(path: &str). The idea is that I don't want to copy-paste all the volume manager code (selecting the volume, getting the root directory etc) all over the place. Instead, I want to get back a clean file handle that I can use to read/write etc.

Because file handles are derived from the volume manager, volume, and root_dir this this doesn't work since, upon returning from get_file_handle they would get killed. I've tried several ways of getting around this, but none seem to work. What's the "correct" way to do this.

Details:
I currently keep the volume manager in a shared, static state behind a mutex. This is because I'm using sdmmc with picoserve which uses tasks/threads. So far the threading seems to work fine.

I'm using the https://esp32.implrust.com/sdcard/write-sdcard.html as the basis of writing to my sd card.

Example of (very) POC function to do this:

Error on return: cannot return value referencing local variable root_dir returns a value referencing data owned by the current function (and the same error for volume_mgr and vol0)

The APP_STATE field is defined like so: pub sd_volume_mgr: Mutex<CriticalSectionRawMutex, Option<Arc<Mutex<CriticalSectionRawMutex, VolumeManager<SdCard<CriticalSectionDevice<'static, Spi<'static, esp_hal::Blocking>, Output<'static>, EmbassyDelay>, EmbassyDelay>, Clock>>>>>,

I'm sure this has to be a common use-case and I'm probably misunderstanding how we should be using sdmmc. Some pointers might help here though!

[thejpster]

If you want handles that don’t hold references to the VolumeManager, you can use Raw Handles for that.

The shell example is probably the most complex example I have currently. That may also be worth a look.

[nsallis]

Hmm the issue there is to use those handles you again have to pull in the volume etc. which is exactly what I'm trying to avoid. I'm thinking throwing those in static Options in a separate module and then writing read/write/stream functions (that handle volume manager etc) on top of those might be simplest in my case and maybe those less interested in the internal workings of the chips. If that seems to work well I'll post back here with an example for others.

[thejpster]

Please note that this crate doesn't have an async API and thus isn't well suited to async applications running on Embassy. You might want to try https://github.com/MabezDev/embedded-fatfs as an alternative, which includes embassy examples and implements the embedded-io-async traits.