forums.ps2dev.org

In my work to improve LaunchELF I've discovered some problems associated with IOP reset.

One of them is that libmc still 'remembers' having initialized with mcInit before the reset, and refuses to allow it to be done again, even though I've loaded new instances of MCMAN+MCSERV to IOP.

I made some slight changes to libmc.h and libmc.c, which eliminated the problem:

In libmc.h I defined MC_TYPE_RESET: In libmc.c I made a slight change to the start of mc_init: Nothing else was altered. In the above I'm not sure if the clearing of cdata.server was needed, but I did that as a safety measure. My real objective was to clear mclibInited, as that flag prevented new mcInit.

I believe that other libs too may benefit from similar 'reset' additions, although this is the only one I've had occasion to investigate yet.

Best regards: dlanor

perhaps mclibInited and friends should be in IOP space and have the rpc server reject a second attempt to init (or usage when not init'd), and send back an error code to the EE. Rather then bending over backwards to get lib* on EE to remain in sync with it's IRX counterpart.
This way you wouldn't need to notify the EE lib should circumstances change in the IOP (such as a reset)

This would cause extra rpc traffic, but wouldn't these instances be errors (or at least rare) and so no real need to optimize them..?

cheriff wrote:perhaps mclibInited and friends should be in IOP space and have the rpc server reject a second attempt to init (or usage when not init'd), and send back an error code to the EE.

I'm not sure if that would be both safe and satisfactory. The EE lib routines probably need to be able to test the validity of some actions without sending any commands to the IOP. Also, I'm not sufficiently sure of how the RPC manager works, to be certain that it can be modified so that an IOP reset has the wanted 'restart' effect on the libs.

Rather then bending over backwards to get lib* on EE to remain in sync with it's IRX counterpart.

I agree. Telling each lib by separate calls could get very messy.

This way you wouldn't need to notify the EE lib should circumstances change in the IOP (such as a reset)

And that is even more important when the current program may have 'inherited' modules from its launcher, without being aware of them...

This would cause extra rpc traffic, but wouldn't these instances be errors (or at least rare) and so no real need to optimize them..?

Not errors, as LaunchELF needs to do IOP reset to get rid of dependencies on other launchers, and will also need to do it after using some modules that ELFs to be launched may want to reuse later.

Since most other programs don't do this sort of thing, LaunchELF will have to deal with those issues both for 'incoming' and 'outgoing' launches, and with proper respect to the fact that LaunchELF itself may browse all PS2 media (using lots of driver modules) between 'incoming' and 'outgoing'. But even so, we are talking of very rare events, typically no more than two per LaunchELF session (which may be quite long, depending on activities).

If it can be safely implemented without having to request reset by each lib, that would be the best, as it eliminates a source of human errors.

Best regards: dlanor