Load HDD modules on BDM config load/save

[xan1242]

Pull Request checklist

Note: these are not necessarily requirements

• I reformatted the code with clang-format
• I checked to make sure my submission worked
• I am the author of submission or have permission from the original author
• Requires update of the PS2SDK or other dependencies
• Others (please specify below)

Pull Request description

Loading of HDD modules before doing BDM operations ensures that the configs can be read off of the internal HDD partition at boot up.

Fixes #1489

[xan1242]

The only other issue that this will cause is the following scenario:

1. User initializes the config off of the BDM HDD
2. Code auto-enables BDM support on auto
3. Doesn't enable HDD support (only USB is enabled)
4. User can't access game config menu because of it

I hope that's not a too big of a deal for now. If it is, I'll take a look at it myself.

And secondly - I cannot test miniInit() to check if it needs this same modification, so I didn't touch it.

[xan1242]

I believe I've fixed that scenario. Other external devices will take precedence before HDD as well (as it used to work before).

As for miniInit(), it all worked already.

[rickgaiser]

This I think is the issue:
There are multiple devices that can be enabled/disabled. The configuration of what device is enabled/disabled is stored on the device.

My proposed solution:

• Place the device configuration on MC
• Load the enabled drivers only
• Load the full configuration from user enabled devices only

Also, treat all device equally. Now USB forced enabled. HDD is treated special, etc...

I see more and more workarounds, loading more and more modules by default. This will make OPL slower and is also not what the user has configured and expects.

I undertand my proposed solution is much more difficult to create, and this PR does not seem 'wrong' to me. So I'll approve the PR and leave it up to someone else to merge it if they feel this PR is needed.

[xan1242]

I agree that this is a tack-on solution when you put it that way. I've only expanded the existing code and continued with its logic.

My general idea was to restore the same behavior on BDM HDD as it was on the classic APA configuration (and as I've described in the issue, reduce reliance on any other external device other than the HDD itself).

So, in that sort of setup, the only way would be to load those modules that correspond to the device itself and that is a problem that you've pointed out.

Wouldn't it be possible (perhaps even in addition to your proposal) to also do the following:

• If the MC doesn't exist, determine the device that OPL was booted from
• Use that as a reference point to load the corresponding modules
• As a last resort, load remaining modules and query the other mediums for configs

Maybe even add an option to allow for device querying (so that it is left up to the user whether the modules load or not).

I do see the code attempted to do something like what I've proposed already, but, it's doing things after the modules were loaded already (I think at least? I'm not too familiar with the codebase, sorry!).

EDIT: Ideally, if there's a way to un-load modules, that'd probably solve most of the performance concerns. But, that's a whole other can of worms, I guess...

EDIT2:

Giving this some more thought, speaking architecture-wise; What I assume the real issue is deep-down, is that you can't unload modules (and that they affect overall performance).

If that is the case, then the only other performant solution is to change which modules load at compile-time (or, at least, at the very start of execution via command line params or something).

Maybe creating some sort of bootstrapper for OPL wouldn't be such a bad idea.

A separate application could handle this very problem by just handling the config reading in its best possible effort (by doing the MC reads and then the queries), then nuking/releasing everything possible, and then passing the parameters to OPL.

OPL could still retain the code that dynamically enables modules (if the user chooses to do it via GUI) in combination with this.

That's just my thoughts on that situation (again, this is all assuming you can't UNLOAD modules to recover lost performance).

[rickgaiser]

Wouldn't it be possible (perhaps even in addition to your proposal) to also do the following:

• If the MC doesn't exist, determine the device that OPL was booted from
• Use that as a reference point to load the corresponding modules
• As a last resort, load remaining modules and query the other mediums for configs

The more I think about it, the more difficult a proper solution is. Why do we even store the config on the same device as where the games are on? This is what causes the current chicken-egg scenario. Also different versions of OPL need different config files. Wouldn't it be better to put the config next to OPL (same folder)?

Makes it more easy to have different OPL versions on one system, like the mainline one, udpbd version, mmce version, grimdoomer version, etc...

Determining the device it was loaded from (and the local folder) seems like a good idea to me, but on ps2 it can be difficult:

• mc*: loaded from MC, no problem
• pfs*: loaded from HDD, no problem
• mmce*: loaded from MMCE, no problem
• mass*: loaded from exFat, device unknown.

If the IOP was not reset by the loader we can ask the still running exFat driver what device it uses (usb/hdd/mx4sio/ilink/udpbd/...). But we can also still use the device in this case to load the config from for instance.

If the IOP was reset by the loader we have no way to find out what "mass" device we where loaded from. The proper way is to change the exFat driver to not use "mass" for everything, but usb0:, mx4sio0, etc... But that's a whole different story.

I do see the code attempted to do something like what I've proposed already, but, it's doing things after the modules were loaded already (I think at least? I'm not too familiar with the codebase, sorry!).

Current codebase is a complicated mess. It's in desperate need of some structural rewrites.

---

For the short term it's probably best to merge this PR though. But for the long term something different to handle configs and devices should be created.

[xan1242]

I think, for the long term - OPL could do the thing Gran Turismo does and just bootstrap itself with the proper module list it needs to load at start via commandline arguments so that the configs can be read off the correct device. That way, the jank surrounding the config reading is practically sandboxed.

That should survive the IOP reset, right? It'll be slower to boot, but it should also be way cleaner and faster internally.

I did a similar thing on PSP a while back when I needed to load a module from kernel space into user space and it worked out pretty well (although, that was a much different scenario).

Either that, or maybe even do code overlays? (That in itself is kinda jank and oldschool lol, but PS2 devs still used it, idk if PS2SDK can even do it)

I know a lot of the codebase parts are workarounds caused by then current state of the homebrew scene (FMCB and others).

However, at some point, you have to cut the fat out and break compatibility with the old stuff and do it properly.

So, that being said, if I catch some free time to work on this I'll experiment with my ideas. I'm very interested in trying things out (but also very aware what challenges await, coming from PSP hacking).

(Or we could just extend Neutrino with OPL features, heh)

EDIT: Now that I think about it even more - chopping up OPL into 2 parts (launcher GUI and loader backend) would probably be the best middleground between Neutrino and OPL as it is now (usability wise).

Features from OPL with the flexibility of Neutrino sounds pretty good IMO.

That is an undertaking onto itself, but, a valid approach nonetheless.

(Also I forgot you were the main dev behind Neutrino for a moment, lol, SORRY about that)