[Sunrisepeak]

Summary

• kal_fs_hard_link (openkal.fs) gives an existing file a second name, in the shape of kal_fs_rename (two directory bases). It is answered per volume by KAL_FS_PROP_HARD_LINKS (bit 16), following the precedent of the operations upon links (clause 11 entry 7). The name being given another is not resolved. Refusals: kal_err_not_found, kal_err_is_directory, kal_err_exists, kal_err_not_supported (two volumes, or a volume that does not claim the position). Clause 11 entry 59.
• kal_process_stop_requested counts the requests to end and skips zero when the count wraps; "zero until a request, non-zero afterwards, never cleared" still holds, so a 0.24 reader is unaffected. Clause 11 entry 60.
• Conformance 0.9.0: observations for both; kal_interfaces() is compared with the implementation manifest's provides-interfaces (named to the suite by tools/run-conformance.sh as OPENKAL_CONFORMANCE_PROVIDES), and the exported names with the same list (by the script, which can read the program's symbols). A manifest that states no list is reported and not compared.
• kit 0.3.0 and the portable example name openkal 0.25.0.

The implementations follow this branch on their own feat/0.25.0 branches (openkal-linux 0.26.0, openkal-macos 0.23.0, openkal-windows 0.21.0), which this workflow's conformance job checks out.

Test plan

• Local: tools/run-conformance.sh openkal-linux ../openkal-linux full,optional: 407 held, 0 did not hold, 5 not observed; the new observations hold; the exported names state the manifest's interfaces.
• Old suite (the conformance suite as it was, read as text): CI run 42675911362 green at e8ad213 — declarations, substitution, conformance for openkal-linux (gcc, llvm), openkal-macos, openkal-windows (llvm, msvc).
• New suite (the suite speaking the mtest protocol through the pinned engine, each job's report in its summary, one report over every implementation): CI run 42679543942 green at fce0dcd.
• Local: mtest 0.5.2 runs the suite three times in a row with the same 425 passed / 6 skipped; list mode, selection by interface and by observation, and a missing selection behave as protocol P3/P4 state.

The mtest migration, and why the suite does not link mtest's library

The suite runs beneath a C library and on a machine with none (openkal-opensbi), so it cannot take a C++ standard library or mcpplibs.os. It speaks the protocol itself (conformance/src/protocol.cpp, level 2): an interface is a case of kind cts that names itself as its clause, each observation a case within it, each measurement of cost a metric. The same reason applies to the implementations' own tests: mtest's library reaches mcpplibs.os, which depends on openkal and on the implementations, so a dev-dependency on it from an implementation would close a cycle through the package under test. Those test programs therefore stay level-0 programs, recorded per program in the mtest store by mcpp test, beside the suite's cases.