Users reported FTP permission refusals again. Since v0.6.7 the title usually
hands itself over at once (to the picker or ES-DE, through LoadExec, which ends
the process), so the start-up repair that opens /app0 to FTP was cut short; and
the picker and ES-DE, other executables, wrote with their own modes.
- Files are 0777 as folders are (were 0666): the link-time wrappers and the
repair (src/permissions_ps5.cpp).
- ps5_permissions_settle waits for the repair (at most a minute) before every
handover: to a frontend, closing the title, the relaunch test.
- ES-DE's library files and folders, the remembered frontend
(src/ps5_frontend_choice.h) and the picker's test record are 0777; the picker
opens RADV's shader cache to FTP after its first 30 frames and again when it
hands over.
Verified on the base PS5: the trace reads "permissions: /app0 checked=17992
repaired=174 refused=0" then "handover waited 596.2 ms"; after a home-screen
launch held at the picker and closed there, an FTP walk of
/data/homebrew/PPSA99169 finds 17992 entries, 0 not 0777 (before: 175 files
at 0666) (evidence/permissions-0777). tools/verify.sh format, unit and
evidence PASS.
EmulationStation draws with PS5_OpenGL, whose Mesa would collide with RADV's
in one image, so it is to be its own executable beside eboot.bin. Whether
LoadExec starts another image in /app0 is measured first: the relaunch test's
arm file takes an optional image ("<count> <run id> [/app0/...]", refused
outside /app0 or with '..'), and tools/run-title.sh --relaunch-image=PATH
uploads a copy of the build's eboot.bin there and removes it afterwards.
Verified:
TMPDIR=build/tmp bash tools/verify.sh -> PASS (format unit build
integration evidence), build 256cb475; the host test covers the image
path, its record and the refused paths
tools/run-title.sh --no-build --relaunch-test=1
--relaunch-image=probe/eboot-copy.bin --watch 45 on the base PS5: the
kernel log shows EXEC /app0/probe/eboot-copy.bin after Kill for LoadExec
=> 0; generation 1 (pid 132) ran from the copy with argv[0] =
"--ps5-relaunch=1" and 419430400 bytes flexible free; PASS, no fatal signal
Evidence: evidence/loadexec-second-image/ (python3 tools/evidence.py compare)
The frontend picker hands over by restarting the title in a new process
(approach B). src/relaunch_ps5.cpp measures that restart: armed by
/app0/relaunch-test.txt (tools/run-title.sh --relaunch-test[=N]), each process
records its generation, argv, flexible memory, pid and clock in
/app0/relaunch-test.jsonl, restarts the title through
sceSystemServiceLoadExec("/app0/eboot.bin", {"--ps5-relaunch=N", NULL}), and
the last one continues into RetroArch. main() now takes the process arguments.
Found on the console: LoadExec's arguments become the new process's whole
argv, with no program name in front (argc=1, argv[0]="--ps5-relaunch=1"); a
home-screen launch gets argc=1, argv[0]="". The first run (build f935ae4e)
read from argv[1] and failed its argument check; the parser now reads from
argv[0] and the host test feeds argv in the console's shape.
Verified:
TMPDIR=build/tmp bash tools/verify.sh -> PASS (format unit build
integration evidence); build identity 453864d6...
tools/run-title.sh --no-build --relaunch-test=5 --watch 60 on the base
PS5 (13.40): 5 restarts, pids 117-122, each with its arguments,
419430400 bytes flexible free at every start, 0.56-0.61 s per restart;
kernel log EXEC x6, "Kill for LoadExec => 0" x5, no fatal signal;
RetroArch started after the chain with XMB assets loaded.
Evidence: evidence/loadexec-relaunch/ (python3 tools/evidence.py compare)