Callback-based system.

[DarkMatterCore]

Is your feature request related to a problem? Please describe. Back when I designed the interface for this library in 2020, it seemed like a no-brainer to use an event-based system based on the ABI used by multiple Switch background services, which in turn makes it possible for the application using the library to span a single additional background thread that uses waitMulti() to handle multiple events and call it a day.

However, this very same reasoning falls short if the application using the library doesn't use events at all, which is something I never stopped to consider. This forces the developer to span an additional background thread to exclusively handle changes from the library, which is a bit overkill.

Please consider this library was specifically designed with nxdumptool in mind before it became a much broader project, and that application relies heavily on background services that do use this kind of ABI.

Describe the solution you'd like A callback-based system that uses a function pointer provided by the user to handle UMS status changes under the library's very own background thread.

This new system should be able to co-exist with the current event-based system, because both designs have their own particular use cases.

Additional context Initially proposed by averne and discussed in #26.

[averne]

Additionally this could be used to enable advanced communication with the user. For instance, there could be a callback used prior to creating the fs context and mounting to devoptab, where the user could decide on a different mountpoint, if he wants to mount as read-only, maybe even have advanced settings based on the filesystem, ...

[DarkMatterCore]

Sure thing. This will be an ongoing WIP I intend to further explore over the course of the next week.

Changes will surely be pushed to dev, so feel free to take a peek at that branch and/or let me know if you want write access.

[DarkMatterCore]

Just pushed the first changes related to this issue to dev, check 0299eaeff8dc4f1fabbb623ba06af371ea756464. A single callback is used at this moment, others may follow down the road.

I tested it a bit with all my flash drives and it seems to work fine.

[averne]

Thanks for the quick patch, I'll try to move my app to this system soon and give you feedback. At a glance, I think the UsbHsFsPopulateCb could take an additional void* parameter, passed by the user in usbHsFsSetPopulateCallback. This way the user can conveniently access any kind of structure (eg. a drive manager object) from the callback.

[DarkMatterCore]

@averne Had some time to spare, so I went ahead and implemented support for a user data pointer in 2c401e832d706f397d5780117c6559106b0d8f3d. I'll be waiting for your feedback, there's some other stuff I want to tackle in the meantime.