Implement sceSysmoduleLoadModuleByNameInternal - #4830
Conversation
This reverts commit 24e50f4.
StevenMiller123
left a comment
StevenMiller123
left a comment
There was a problem hiding this comment.
Mostly looks good to me, just some minor nits.
StevenMiller123
left a comment
StevenMiller123
left a comment
There was a problem hiding this comment.
Just some more thoughts on this now that the blocking PR (my fixes for Media Player) are now merged.
| std::string filename = std::string(name) + ".sprx"; | ||
| s32 exists; | ||
| using namespace Kernel; | ||
| std::string system_base = std::string("/") + sceKernelGetFsSandboxRandomWord(); |
There was a problem hiding this comment.
I personally think we should tie this into some allow/block list instead of relying on users making game-specific module folders for things calling this (even if it's only called by firmware stuff).
Maybe try to have this use the same array of allowed modules that's currently placed in the loadModule code, with a bypass for modules present in game-specific module folders?
There was a problem hiding this comment.
That's fine by me, do you have a list of safely LLEable modules loaded through this function perchance?
There was a problem hiding this comment.
Been too long since I glanced at VSH, I forget what all it tries loading through this.
2 participants
Force-LLEing stuff from sys_modules/title_id/ is already a thing, and this PR makes that possible for apps that use the internal function sceSysmoduleLoadModuleByNameInternal to load modules instead of the standard API for games, such as VSH. This by itself is not enough to satisfy module loading logic for that though, at least not in a clean way, as some modules ideally should be skipped without reporting an error, so it can both proceed, while at the same time we don't have to deal with having to emulate even more stuff for misc libraries.
I only tagged Stephen in one commit, but his contributions were more encompassing than just that one addition.