sceSaveDataInitialize3 started the callback delivery thread for every
title that initializes save data, though nearly none register a
callback, and could throw there if scePthreadCreate failed. The thread
now starts at the first successful sceSaveDataRegisterEventCallback of
an initialization, under the calling, g_slots_mutex and callbacks.mutex
locks that registration already takes, so a title that never registers
gets no thread and sceSaveDataInitialize3 is again only the count.
A replacing registration, one from inside a callback and one after an
unregister reuse the running thread; a refused one starts nothing.
The last sceSaveDataTerminate still takes the worker out under
g_slots_mutex and joins it outside the lock, and only when one was
started, so a session that registers between that terminate's detach
and its join starts its own thread.
The tests run two sessions with no registration, and on Linux count the
process's threads to check that Initialize3 and a refused registration
start none, that the first registration starts one and later ones reuse
it, and that the final terminate joins it.
sceSaveDataRegisterEventCallback and sceSaveDataUnregisterEventCallback
were parameterless declarations that threw. They now follow shadPS4
#5226: registering before initialization is NOT_INITIALIZED, a null
callback is PARAMETER, a second registration replaces the callback and
its userdata, and unregistering needs no initialization.
Every backup completion that queues an event for
sceSaveDataGetEventResult, type 2 from sceSaveDataBackup and type 1 from
sceSaveDataUmountWithBackup, is queued for polling first and then handed
to the callback registered at that moment. A library thread delivers it:
sceSaveDataInitialize3 starts it with scePthreadCreate, as
libSceUsbStorage starts its monitor, so the callback runs on a guest
thread, and the last sceSaveDataTerminate joins it. Unregistering waits
for a running callback and drops completions not yet delivered, and a
terminate from inside the callback returns BUSY instead of joining its
own thread, as shadPS4 does.
guest_savedata_event_callback covers the errors, both event types, the
delivering thread, unregistration, replacement, a terminate from inside
the callback and an idle terminate followed by a restart.
ntamas94 ran sceSaveDataCheckBackupData, sceSaveDataRestoreBackupData
and sceSaveDataUmountWithBackup on a PS4 Pro with firmware 10.71's
system libSceSaveData.sprx. The console agrees with this library on
every case it covers. Two of its rows go in the debt file: another
title's titleId returns NOT_FOUND, and sceSaveDataDelete drops the
save's backup as this library does, which the entry called unknown.
The run also shows the check returning PARAMETER for a param buffer
filled with 0xAA, and 0 for a zeroed or null one. Which bytes the
console checks was not measured, so the check is not changed; a new
entry states the measured cases and that the byte set is unknown.
Three entries in the libSceSaveData.native debt file: a failed restore
leaves the live save as it was, and where a crash during a restore or a
backup leaves the save and its backup, since neither is recovered at the
next start; and that on Windows directory entries cannot be flushed, so
crash safety there rests on NTFS journaling and is not shown.
The declarations now live in libSceSaveData.native/Export.cpp, which both
save data libraries are built from, so their entry belongs in that
library's debt file.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
AnyPS5 resolves a title's imports by NID, so a title that imports a system
function no library provides fails to load with an unresolved import. The
PS5 3.20 export inventory lists 193 such exports across 37 PS5 system
libraries AnyPS5 implements but does not provide.
Declare them as throwing stubs so those titles load and reach their next
blocker. Each declaration calls NotImplemented_nid_no_patch and returns 0;
none of them implements the function. Declarations with a credible
prototype use it and cite the source with a pinned commit, and the rest
are declared without parameters, which resolves the import without making
an ABI claim. The technical-debt files record the limitation per library.
libSceMbus and libSceSystemService are left out because pull request #7821
declares them. libSceAgc is left out because its exports are versioned, so
the 3.20 NID names a different symbol from the one AnyPS5 ships.
libSceAvPlayer.native is left out because it compiles libSceAvPlayer's
Export.cpp.
Names and NIDs come from the PS5 3.20 export inventory at
https://github.com/DNNDHH/PS5-3.20_Libs/tree/b2a77c09cd71c01f34c790cfbe98c751a13262ad
The PS5 references count save data differently from the PS4: SharpEmu
uses a 64 KiB block, and SharpEmu and KytyPS5 allow 48 to 16384 blocks
per save, which at 64 KiB a block is 3 MiB to 1 GiB, the PS4's byte
range. The module used the PS4 values, 32 KiB blocks and a 32768-block
maximum. At 64 KiB a block, sceSaveDataDirNameSearch and
sceSaveDataGetMountInfo therefore counted up to twice the blocks a
save's files use, and a save without a recorded size reported 32768
blocks, which is 2 GiB.
The search test now expects 64 KiB blocks and the 16384 maximum, and
the block accounting gets its own technical debt entry.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Yunus Shaikh