@aldostools
@Evilnat
Do you guys know whether or not there was a specific reason for using a slot system for map_path in Cobra/Mamba/HEN?
You are probably the only people left standing who might have answers for me at this stage. [emoji6]
I have made a number of changes to the code, added a mutex, replaced the preallocated array of Mapentry structs by a linked list of Mapentry dynamically allocated/deallocated, I am now considering removing the maximum threshold of mappings.
I removed the slot system altogether for the time being, hence my question above, just in case I am missing something and the slots are somehow important enough to be kept.
The only thing I could think of was that the slots might have been used for prioritizing mappings when a path could fit more than one mapping, for instance if folder mappings are involved, speaking of which, are folder mappings actually supposed to be supported by the map_path syscall? Quite frankly, the original code does not seem solid enough to support that kinda stuff properly.
If I don't reintroduce the slot system, I will probably have to implement alternate map_path/get_map_path syscall 8 subcommands, to ensure there's no issue with legacy homebrew that may be using that stuff. Feel free to make suggestions if you have any.
As far as I know, there is not documentation about why map_path was coded that way.
My guess is because the payload needed a vector with the list of mapped paths to compare the them in the open_path_hook and in sys_aio_copy_root.
The vector provides an easy way to know which paths were mapped, so they can be removed easily if you need a clean system.
Also the main purpose was mapping game paths (e.g. folder games) and maybe a couple of files. So 16 slots was more than enough.
Lately map_paths has gained relevance because it's now used for modding, redirection of system files, mount games and many other applications.
The original code was very basic (add, remove, remove all, and path redirection in open_path_hook or sys_aio_copy_root).
Now it has more features like homebrew block, rif activation, re-enable syscalls, shadow paths redirection, locked mappings, etc.
To allow more applications, the slots were increased to 32.
Also there were changes in the scanning algorithm to make is more efficient, and reduce the loops and string handling.
I also added get_map_path() and an opcode to access it to have a way to get information of the current mappings.
However I think that function needs to be reviewed. The last time I tried to use it I couldn't get the proper information.
One of the main issues that I found is mapping/unmapping subfolders when the parent path is already mapped.
e.g. mapping/unmapping /app_path/PS3_GAME when /app_path is already mapped.
Depending the order in which they were mapped, the path of /app_path/PS3_GAME can be different.
Also mapping between /app_home and /dev_bdvd doesn't work, and some mappings to /dev_flash fail or cause a system panic.
