[orezraey]

What

pathconf measured on a retail PS5 (firmware 13.60) through libkernel_sys.sprx's own pathconf from a payload process, over every name from 0 to 70 on 22 paths. The sources and console logs are in this gist (ppathconf2, ppathconf3).

The answer depends on the mount. The console has at least five sets: /data and /user; /, /system, /hostapp, /preinst and /update; tmpfs (/system_tmp, /mnt/sandbox, /mnt/usb0); devfs (/dev/null); and UFS (/system_data).

AnyPS5 already answered with FreeBSD's UFS constants, and those match /system_data for every name it answered. It threw for the rest; they now return what /system_data returns:

• _PC_ALLOC_SIZE_MIN, _PC_REC_INCR_XFER_SIZE, _PC_REC_MIN_XFER_SIZE and _PC_MIN_HOLE_SIZE: 65536;
• _PC_REC_XFER_ALIGN: 16384;
• _PC_ACL_PATH_MAX: 3;
• _PC_ACL_EXTENDED, _PC_MAC_PRESENT and _PC_ACL_NFS4: 0;
• _PC_MAX_CANON, _PC_MAX_INPUT, _PC_VDISABLE and _PC_ASYNC_IO: EINVAL.

The lookup errors already matched: EFAULT for a null path, ENOENT for an empty or missing one, ENOTDIR under a file, and ENAMETOOLONG for 1024 bytes or a component over 255.

Not followed: /app0, /savedata0, /temp0 and /download0 do not exist in a payload process, so what a title sees there is unknown. The debt entry lists how the other mounts differ.

Tested

• Head after merging main (f26434afa3, with refactor(libs): add full export headers for libs #10706): 88bf509e20. The test takes its declarations from the library headers and drops the unused PathconfThrows. guest_kernel_sys passes three runs in a row on Windows (MinGW) and on Linux (WSL Ubuntu, GCC); public_headers audit and check_conventions pass.
  Windows 11, MinGW (winlibs).
• guest_kernel_sys checks every newly answered name for a file and a directory through pathconf, fpathconf and _fpathconf, and EINVAL for the four names above (_PC_ASYNC_IO stays 200112 for the descriptor forms). It throws on main and passes three runs in a row with the change.
• tools/check_conventions.py passes.
• feat(libkernel_sys): implement fpathconf and _fpathconf #10060 landed first, so main is merged in and these values now live in its PathConfigurationValue. fpathconf and _fpathconf on a file or directory answer them too, since FreeBSD 11's kern_fpathconf asks the same VOP_PATHCONF; pipes and _PC_ASYNC_IO keep feat(libkernel_sys): implement fpathconf and _fpathconf #10060's handling.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: fix(libkernel_sys): answer fpathconf on a socket as FreeBSD answers it for a pipe #10427, feat(libkernel_sys): implement lchflags #9442, feat(libkernel_sys): implement scePthreadMutexIsowned, the switch hooks, utrace and tcsetsid #9713; feat(libkernel_sys): implement lchflags #9442, feat(libkernel_sys): implement scePthreadMutexIsowned, the switch hooks, utrace and tcsetsid #9713 edit the same lines too (merge order only); refactor(libs): add full export headers for libs #10706 edits the same lines too (merge order only); lands before feat(libkernel_sys): implement kenv #11032, which changes PathConfigurationValue too (Gruzzberry agreed to refresh it)
• Fixes: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

[MarcZX10]

Reviewed exact head 9fc8d159bdecb858e6a72741b0822fd7b58d1171. The measured /system_data values are narrowly applied to names that were previously unimplemented, while the existing lookup-error behavior remains covered; the added test cases exercise file and directory paths, and hosted eligibility/conventions/labels/report checks pass. One contribution-rule item remains unresolved: the PR itself says #10060 moves the same pathconf switch into PathConfigurationValue and that the second branch must carry the first branch’s values, but the checklist still says Depends on: none and the body records no agreement with #10060’s author. Please coordinate the landing order with that author and update the dependency line accordingly, preserving both sets of behavior whichever lands second. I am not asking either author to close work; this is only the required overlap sequencing.

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
PR 11032	core/libs/prx/libkernel_sys/Export.cpp L133-134

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 5021	core/libs/prx/libkernel_sys/Export.cpp
PR 7201	core/libs/prx/libkernel_sys/Export.cpp
PR 9097	core/libs/prx/libkernel_sys/Export.cpp core/libs/tests/GuestKernelSys.cpp
PR 9297	docs/dev/debt/libkernel_sys.md
PR 9302	docs/dev/debt/libkernel_sys.md
PR 9826	core/libs/prx/libkernel_sys/Export.cpp
PR 10657	docs/dev/debt/libkernel_sys.md

[orezraey]

@xXPBSXx #10060 moves the pathconf switch this PR extends into PathConfigurationValue. I propose #10060 lands first; I'll then merge main here, move the measured /system_data values into that helper and rerun the pathconf tests. I set Depends on: #10060 on this PR. Does that order work for you?

[oneandonlydean]

@orezraey on the landing order with #10060 that MarcZX10 raised there: #10060 lands first. It is reviewed and in its final CI run. Once it has merged, please merge main into this branch, keep both implementations in core/libs/prx/libkernel_sys/Export.cpp and both entries in docs/dev/debt/libkernel_sys.md, as your description already offers, and change this PR's checklist to "Depends on: #10060". #10060 needs no change for this.

[orezraey]

Refreshed after #10060 landed (f32fd62): main is merged in and the measured /system_data values now live in its PathConfigurationValue, so fpathconf and _fpathconf answer them for files and directories as well, while pipes and _PC_ASYNC_IO keep #10060's handling. The libkernel_sys.md entry combines both. guest_kernel_sys passes three runs in a row and check_conventions passes; the description is updated.

[orezraey]

@Gruzzberry @simonbronk: #9442 and #9713 change the same lines as this PR in core/libs/tests/GuestKernelSys.cpp (git merge-tree of both heads over current main conflicts there). I propose they land first; I will then merge main into this branch, keeping both sides' behaviour, and rerun its tests. Depends on now lists them (merge order only).

[orezraey]

@boykopovar: #10706 changes PathconfThrows in core/libs/tests/GuestKernelSys.cpp, which this PR removes because every name it covered now returns a measured value; git merge-tree of both heads conflicts only there. I propose #10706 lands first; I will then merge main into this branch, drop the helper again if nothing else uses it, and rerun guest_kernel_sys. I listed it in Depends on (merge order only).

[orezraey]

@Gruzzberry #11032 adds the kenv code right before PathConfigurationValue in core/libs/prx/libkernel_sys/Export.cpp and gives it a function argument, while this PR rewrites that function's answers, so the two conflict there. I propose #11032 lands first; I will then refresh this PR over it, keeping your kenv code and the new argument and applying this PR's measured pathconf values. Depends on lists it (merge order only).

[Gruzzberry]

Hi @orezraey, the overlap check shows my open PR next to this one:

• feat(libkernel_sys): implement kenv #11032 (kenv) changes lines next to yours in core/libs/prx/libkernel_sys/Export.cpp L133-134

The changes are separate. Only the neighbouring lines overlap. Proposed merge order: this PR first, then #11032, which I'll rebase onto it after it merges. I've recorded that under Depends on in #11032. If you'd prefer to go second, say so and I'll switch it.

[orezraey]

Thanks @Gruzzberry, agreed: this PR lands before #11032. I updated the Depends on line here so it no longer waits for #11032.