Responsive to the question, “Is it a pain to implement MTP”.
I would say MTP is a significant amount of code to write, and an even more significant surface area to test.
In my experience, the cost of testing dwarfs the cost of development, and if that cost isn’t paid upfront, it is simply deferred to time when the code is already out and in-use by end-users. Thus, I consider testing capability (and costs) integral to the cost of the feature.
At a minimum, the device firmware would need to hook into the file system (and format commands), in order to ensure a new unique ID is generated for each file change, and to queue notification events for those file changes.
One significant pain point is the large amount of code that must be working, before any portion can be tested.
Then there are the less obvious pain points, such as all the edge cases that need to work properly, to avoid equivalents of the file system corruption issues (that will continue to plague the current multi-initiator storage device model). e.g.,
- What happens when the database is only partially updated due to power loss?
- How do you detect a file was updated when the database file hasn’t also been updated?
- How to handle host-side interactions to a file or directory with an open handle in the firmware?
- How to handle a failure to queue an event to notify the host of a change?
- How to ensure a uniqueID is not re-used, especially where the volume is reformatted?