This moves each context's cwd state into somewhere in relibc. Thus, the kernel enforces that paths contain a scheme part in every SYS_OPEN call (it doesn't check for . and .., but schemes will still not have to handle those and can simply ENOENT if they find any. It might also be a good idea to not modify the paths if they do contain . and/or .., as userspace might for example want to support arbitrary paths.
The rationale for removing SYS_CHMOD is that it has been deprecated for three years (since 0.1.55), and has long since had a relibc replacement using fchmod. Removing chmod is nothing in terms of ABI compatibility compared to removing fexec and clone.
This reduces the number of filesystem operations started by the kernel, and simplifies future completion-based I/O (read: io_uring), a lot.
Blocked on syscall!71 (merged)