testing/ostest: Split the fork test into vfork and fork.

[casaroli]

Depends-On: apache/nuttx#19562

Summary

apache/nuttx#19562 separates fork() and vfork(), which NuttX implements as the same function. This gives each one a test of its own.

ostest's "vfork" test was never testing vfork(). It has the child write a global and the parent observe the write — the defining property of sharing, not of vfork(), whose defining property is that the parent is suspended and whose contract forbids the child to write anything at all. It passed because both names resolved to the same sharing primitive.

vfork.c is rewritten to test what vfork() promises. The child does only what POSIX permits — it calls _exit(42) and nothing else, not even exit(), which would run atexit handlers and flush stdio in the parent's address space. Since the child may not write memory and the parent cannot run while the child lives, the observable is the child's exit status: had the parent not been suspended, it would have reached waitpid() while the child was still alive. Where child status is not retained — ostest_main() sets SA_NOCLDWAIT for the whole run, deliberately — ECHILD is accepted as equally good evidence, since it says the child was already gone when the parent asked.

fork.c is new and tests POSIX fork(): the child's writes to .data, .bss and the heap are invisible to the parent and vice versa, a pointer to a stack local taken before the fork names the same object in both, and the child does everything a vfork() child may not — calls malloc() and printf(), and returns from the function that called fork().

Both run at the top of user_main(). They exercise the lowest-level machinery in the suite — address environments, stack setup, the architecture's register context — so a fault in one takes the process down instead of reporting a failure. That matters more than usual right now, because ostest does not currently run to completion on any target: it aborts later in timedmutex_timeout_regression_test() at timedmutex.c:185, added by master eea8384 and unrelated to this PR. Running first is the only reason the fork tests run at all.

Each test gates on the one primitive it tests, ARCH_HAVE_VFORK and ARCH_HAVE_FORK respectively. There is no compatibility layer and no mapping between symbols. vfork.c no longer requires SCHED_WAITPID: the suspension lives in the kernel primitive now, so the test's core assertion holds without it and only the status check is conditional.

The other in-tree callers are audited for which primitive they actually meant:

• interpreters/python's _posixsubprocess and netutils/libwebsockets' LWS_HAVE_WORKING_VFORK want the fork-then-exec path — ARCH_HAVE_VFORK.
• python's os.fork() and libwebsockets' LWS_HAVE_FORK mean real fork() and stay on ARCH_HAVE_FORK, so they become absent rather than silently wrong.
• testing/fs/fdsantest's vfork case follows ARCH_HAVE_VFORK.

interpreters/bas is deliberately left alone. Its SHELL and EDIT statements reach for vfork() under an ARCH_HAVE_FORK guard and want the same treatment, but checkpatch.sh checks the whole of any file a patch touches and bas_statement.c produces 1681 pre-existing findings against master, so a one-line change there fails CI on its own. The consequence is small: EXAMPLES_BAS_SHELL is EXPERIMENTAL and already depends on ARCH_HAVE_FORK, so it becomes unselectable rather than misbehaving.

Ordering

This PR must merge after apache/nuttx#19562, because the symbols each test keys on do not exist until it lands.

It is not a blocker for that PR's CI. The apps changes that unblocked it were #3673, which merged on 2026-08-03 — nothing in apps master calls fork() unconditionally any more, so apps master builds against #19562 as it stands. Two commits from this branch's earlier revision were part of that PR and have been dropped in a rebase onto current master; what remains is one commit.

Between apache/nuttx#19562 merging and this PR merging, ostest has no fork test. That is the deliberate cost of carrying no compatibility layer.

fork_test() costs nothing on size-constrained configurations, because it is not built on them. It keys on ARCH_HAVE_FORK, which no architecture sets until up_addrenv_fork() lands for it, so lm3s6965-ek:qemu-protected — the configuration with the tightest user flash region — never compiles it. It is exercised by the per-architecture PRs that follow, which are what turn ARCH_HAVE_FORK back on.

Testing

Host: macOS 15 (Darwin 25.5.0) on Apple Silicon. QEMU 11.0.3, xPack riscv-none-elf-gcc 14.2.0-3, Arm GNU arm-none-eabi-gcc/aarch64-none-elf-gcc 14.2.rel1, xtensa-esp32s3-elf-gcc 12.2.0.

../nuttx/tools/checkpatch.sh -c -u -m -g <base>..HEAD, the exact command .github/workflows/check.yml runs — ✔️ All checks pass, with codespell, cvt2utf, cmake-format and nxstyle installed.

vfork_test() passes on raspberrypi-pico-2:nsh (real RP2350), qemu-armv7a:nsh, qemu-armv8a:nsh, rv-virt:nsh64 and sim:nsh, built against apache/nuttx#19562:

user_main: vfork() test
vfork_test: Started
vfork_test: Child 5 ran and exited before the parent resumed

esp32s3-devkit:ostest on real ESP32-S3 hardware builds and boots clean with neither test compiled in — Xtensa selects neither ARCH_HAVE_VFORK nor ARCH_HAVE_FORK and has no fork entry point, so it is the "architecture this does not touch" case.

fork_test() is not exercised yet by construction: no architecture selects ARCH_HAVE_FORK until a per-architecture PR implements up_addrenv_fork().

[xiaoxiang781216]

why not move to #3673

[xiaoxiang781216]

why not move to #3673

[xiaoxiang781216]

why not move to #3673

[github-actions]

🔗 Cross-repo PR dependencies

The read-only Build run reported the following dependent PR(s) and fetched head SHA(s):

• !sched/arch/libc: Give fork() and vfork() their real, separate semantics. nuttx#19562 @ 91321567be

CI run: https://github.com/apache/nuttx-apps/actions/runs/31246994111