ENOSYS for fork/pipe/socket/chmod/symlink/copy_file_range blocks POSIX-style CLI workloads; one startup path jumps through a NULL stub

[yspbwx2010]

Context: full C++23 modules workspace (7 members, ~2k compile units) now
compiles and links statically via the native path (mcpp v2026.8.26.2 +
openkal-llvm-runtime@0.1.3 + openkal-linux@0.5.4 + openkal-musl@0.3.5,
x86_64-linux-musl). Zero PT_INTERP — the compile/link line is in good
shape. The runtime line is where we hit a wall: our test suite runs 94
cases; 67 pass, 27 fail, and every failure reduces to a kernel-layer gap.

ENOSYS inventory (from test failures, deduplicated)

syscall surface	observed failure
fork	"fork failed: Function not implemented" — no subprocess can be spawned
pipe / pipe2	"pipe2 failed: Function not implemented"; stdout capture pipes fail
socket listen (bind/listen/accept)	local HTTP callback server cannot start on any port
chmod / mode bits on create	files expected 0600 land 0777; dirs expected 0700 land 0777
symlink / symlinkat	std::filesystem::create_symlink / create_directory_symlink → ENOSYS
copy_file_range (or sendfile)	std::filesystem::copy_file → ENOSYS

Also observed: std::filesystem::last_write_time on a directory returns
"Is a directory". The produced binary SIGSEGVs during early terminal-UI
initialization (after spawning threads): gdb shows PC=0 with an empty
backtrace — a call through a NULL function pointer, i.e. some stub in the
kernel/libc layer is a null pointer rather than an ENOSYS-returning
function. A stub table entry that returns -ENOSYS consistently would at
least let programs fail gracefully.

For an interactive CLI that shells out (the classic
fork/exec/pipe/waitpid loop), the current surface is not yet sufficient.
Is fuller POSIX process/socket/fs coverage on the roadmap for
openkal-linux, or is the intended scope embedded/compute workloads? Happy
to contribute test cases or a syscall-by-syscall reproduction list.

[Sunrisepeak]

Answered in openkal-musl 0.5.0, openkal-macos 0.5.0 and
openkal-windows 0.3.0, all published and in the index. Six of the seven
items work now; the other two are refused in terms, and the reasoning for
each is below because a refusal without one is indistinguishable from an
oversight.

⚠️ The specification did not change. openkal 0.8 already carried every atom
these need. What was missing was the route: musl's network sources compile and
issue system calls the port had no case for, so they reached its default: arm.

What now works

	how
socket, bind, listen, accept, connect, send/recv, shutdown, getsockname/getpeername	openkal.net. ⚠️ BSD makes a socket first and decides what it is afterwards; openkal has no object between "nothing" and "a connection", so a descriptor made by socket holds the three numbers it was given and the openkal operation happens at connect, or at listen once bind has recorded where
UDP, whole surface	openkal.datagram
poll, select, O_NONBLOCK, SO_RCVTIMEO	openkal.timeout. openkal has no operation reporting whether a transfer would proceed (clause 6.3 records why), so poll performs a bounded transfer and keeps what it produced for the read that follows
pipe, pipe2	already worked; O_NONBLOCK on one is now honoured rather than accepted and ignored
fork	openkal.space + setjmp/longjmp. See below
copy_file_range	already worked
posix_spawn, system, popen	already worked — port/src/okm_spawn.c has replaced musl's since the port was written. What was missing was a test, and there is one now

fork — an earlier answer of ours was wrong

We had said the specification deliberately declined it. Half of that is right:
clause 7.1 declines to duplicate an address space and its execution state.
openkal.space supplies the first half by itself, and space.h states in terms
that a library above reaches fork by saving its own execution state before the
call and restoring it in the started context — "that is composition, and it
belongs above this line."

So fork is composed in the port. Two things a caller can tell, both recorded
in musl/PATCHES.md: the copy rebinds its per-context slot (kal_task_current()
promises uniqueness among contexts running at the same moment and says nothing
about a copy — the implementations differ), and the copy's view of the table of
started programs is cleared, because POSIX says a duplicate has no children.

chmod and symlink — refused, and why

chmod reports ENOSYS. kal_node_info carries {size, modified_ns, kind, writable} — one boolean, not a mode word — and kal_fs_open_file takes
flags rather than a mode. Mapping the owner-write bit onto writable would make
chmod(0600) succeed and stat report something else, which is a worse failure
than the one you reported: "expected 0600, refused" is something a caller can act
on; "expected 0600, got 0777" is not.

We considered asking the specification for a permission operation and declined:
a FAT volume, a UEFI system partition and a Windows access-control list do not
share a model, so an operation upon permissions is one that some resources of the
interface can never satisfy — which clause 6.4 excludes.

symlink reports ENOSYS. SURFACE.txt has no operation that creates or
reads a link. It does have kal_node_link as a node kind and
KAL_FS_PROP_LINKS as a property word, so an implementation can report a
link it meets and cannot make one. That asymmetry is the specification's and
is now recorded rather than worked around; whether links enter 0.9 is open.

The NULL stub

Every route added takes a weak reference and tests it before calling, and
continuous integration asserts that for eleven names with a required interface
as the control. A backend that declines an interface therefore yields ENOSYS
rather than a jump through zero — which is the difference between a program that
fails and one that cannot say why.

And it is not Linux-only

openkal-macos gained all five interfaces and openkal-windows four of them
(openkal.space is declined there: this system starts a named program and has
no primitive that copies an address space, so kal_space_start fails at the
link naming the operation). The same POSIX probe — 35 observations, naming no
openkal symbol — runs on Linux, macOS and Windows.