Both call libkernel's pthread_mutex_init and pthread_mutexattr_init and
return 0x80020000 | errno on error, as shadPS4 (ce74386) exports them as
ORBIS(posix_pthread_mutex_init) and ORBIS(posix_pthread_mutexattr_init)
and ChonkyStation4 (c101a23) maps them to its POSIX init functions. A
mutex made without attributes is error-checking. FreeBSD 11.4's
malloc-internal _pthread_mutex_init_calloc_cb makes a normal mutex
instead; the gap is recorded in the libkernel_sys debt file.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
kldstat was a NotImplemented stub. It now follows FreeBSD 11.4's
sys_kldstat (sys/kern/kern_linker.c): only the version field is read
(EFAULT when that fails), and a version other than 1056
(struct kld_file_stat_1) or 2080 (struct kld_file_stat) is EINVAL.
No linker file is listed here, as for kldnext, so every file id then
gets ENOENT and the structure is never written.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Keep a copy of the name with the semaphore and move the export from the libkernel_sys stub into libkernel next to the other sem_* exports.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
The PS5 3.20 export lists have ksem_* in libkernel as well as
libkernel_sys, and on Windows a libkernel import never reaches
libkernel_sys, so titles importing them from libkernel did not find
them. Following pipe1os's review on #9284, also: ENOSPC from
ksem_init when no descriptor is left, the SEM_MAX limit of 30 with
ENOSPC, and dup/dup2 from a ksem id throwing as for a kqueue.
_fpathconf_nid_postfix only treated FIFOs and sockets as descriptors without
a vnode, so a kqueue or shm_open descriptor fell through to the UFS constants
(LINK_MAX 32767, NAME_MAX 255, PIPE_BUF 512). FreeBSD 11.4 kern_fpathconf
(kern_descrip.c:1411-1429) answers _PC_ASYNC_IO for every descriptor and
returns EOPNOTSUPP for a no-vnode descriptor that is not a pipe or socket.
Return EOPNOTSUPP for kqueue and shared-memory descriptors.
Co-Authored-By: Claude Opus 4.8 <[email protected]>
Follow FreeBSD 11.4 sys_kenv: KENV_GET, KENV_SET, KENV_UNSET and KENV_DUMP over
an in-memory kernel environment of at most 512 variables, with the 128-byte
name and value limits, ENOENT, EINVAL, ENAMETOOLONG and EFAULT.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
They still throw through NotImplemented_nid_no_patch; only the parameter
lists and, for sceKernelLwfsLseek and sceKernelLwfsWrite, the 64-bit return
type change. The only source is the PS4 OpenOrbis libkernel.h.
Follow FreeBSD 11.4's sys_kldsym: EFAULT for an unreadable lookup
structure, EINVAL for a wrong version or command, EFAULT or
ENAMETOOLONG for the symbol name, ENOENT for a negative file id. Any
other lookup throws, as no kernel module is modelled. Adds
GuestCopyIn_nid_no_patch for the checked structure read.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
sigreturn applies FreeBSD 11's amd64 sys_sigreturn checks:
- EFAULT for a null context;
- EINVAL for unknown mc_flags, and for rflags bits outside
PSL_USERCHANGE that differ from the current flags;
- set_fpcontext's FPU format and ownership cases.
It then restores the context through the path setcontext uses, which
now lives in RestoreContext. A non-user %cs and an extended FPU state
still throw.
FreeBSD 11's sys_sched_setscheduler checks: a null parameter is EFAULT,
another process is ESRCH and an unknown policy is EINVAL. Pid 0 sets the
calling thread through scePthreadSetschedparam. Values that call
rejects, and the guest's own pid, whose first thread is not tracked,
still throw.
An owner or group other than the guest's (0) or the unchanged value
returns EPERM after the path lookup, as FreeBSD 11's chown(2) does for
a caller without the superuser privilege. That is the answer #8457
gives for fchown. A lookup error still comes first.
ProsperoEden declares the setter with the mode as its argument and the
getter with an int output, and measured on a PS5 that modes 0 and 1 are
accepted, 2 to 7 return 0x80020016 and 1 is the default. Both threw as
discovered stubs. Other modes and a null output throw.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
linkat threw for a symbolic link as the source without
AT_SYMLINK_FOLLOW. FreeBSD 11.4's kern_linkat looks the source up with
NOFOLLOW in that case and links the symbolic link itself, also when it
dangles or names a directory, since the link is not a directory. On
Linux and macOS the host's linkat with flag 0 does the same, so the
source is linked there after the usual destination checks (EEXIST, then
ENOTDIR or ENOENT for the parent). Windows still throws.
Dean