Skip to main content
How Can We Help?
< All Topics
Print

PSP Filesystem and I/O Model

Posted
Updated
ByJstar269

Type: REFERENCE   Status: MAINTAINED   Scope: PSP device namespaces, descriptors, synchronous/asynchronous I/O, and safe host mapping

PSP file I/O is a device and descriptor model. A compatibility runtime must preserve the guest-visible namespace, descriptor type, path semantics, asynchronous state, callbacks, and containment policy. It is not enough to pass a PSP path to a host fopen.

How We Know

guest "disc0:/DATA/FILE.BIN"
          |
          v
device namespace + path normalization
          |
          v
contained backend (ISO / source-owned host fixture)
          |
          +--> descriptor type and offset state
          '--> sync or async completion + optional callback
Source-owned I/O containment diagram.

Namespaces and paths

PSP software addresses devices such as disc0:, ms0:, host0:, and firmware partitions through PSP-visible names. Case, separators, directory semantics, device assignment, and path normalization are part of the guest contract. A host directory is an implementation backend, not a PSP namespace.

Savedata, utility dialogs, and media containers are higher-level subsystems. They may use file I/O but add policy and state that ordinary byte-copy logic does not capture.

Descriptors are typed guest objects

PRIOR ART: PSPSDK uses SceUID/SceUID fd handles for files, directories, and other kernel objects. A runtime should keep descriptor type, open flags, current offset, device ownership, and lifecycle separate from the host file handle.

  • Reject stale or wrong-type handles deterministically.
  • Keep directory enumeration state separate from file offsets.
  • Preserve signed return/error values and 64-bit offsets where the API exposes them.

Synchronous and asynchronous I/O

The public API has synchronous reads/writes and async variants with poll, wait, callback-aware wait, cancel, status, and callback registration operations. Async I/O is a state machine: submitted, pending, completed, cancelled, failed, or consumed. A host task finishing is not automatically a PSP-visible completion event.

Callback-aware waits belong to the callback model; do not implement them as an unrelated polling loop.

Containment and safety

Normalize guest paths before host resolution, reject traversal outside the configured backend, bound path lengths, and keep the mapping read-only unless a named PSP contract requires writes. Never use private game paths or retail assets as public examples. Memory validation still applies to buffers and directory structures.

Do Not Infer

  • An ISO parser is not the complete UMD/filesystem contract.
  • A valid host file is not proof of correct PSP device/path semantics.
  • Async completion is not equivalent to a host future resolving.
  • A typed descriptor namespace is not an untyped integer file table.

Open questions

Source-owned fixtures should cover device prefixes, case/path normalization, partial reads, EOF, directory enumeration, async poll/wait/cancel, callback races, medium absence, and containment failures. Savedata and utility-dialog semantics remain separate pages.

Primary sources

Table of Contents