0.10.0 --- openkal 0.13: a start that did not happen, and whether a node may be started - #21
Conversation
…ode may be started kal_process_spawn answered kal_ok and a handle for a start that never happened, execve's own failure included: the copy replaced itself or exited 127, and the caller had no channel to the difference. A name that does not exist, a directory, or a file with no execute bit all came back as a program that ran and returned 127. Ported openkal-linux's exec-report pipe: this kernel's two-register pipe_pair, close-on-exec set on each end since there is no pipe2 here, both ends lifted above 3 + grant_count with the atomic F_DUPFD_CLOEXEC (67 on this kernel, added to sys.h) so the copy's own placement cannot close them. The copy writes errno after a failed fchdir or execve; the parent reads, reaps the copy on a nonzero value, and returns translate(errno). ENOEXEC (8) now maps to kal_err_not_program. kal_fs_set_executable_at and KAL_INFO_EXECUTABLE, answered on APFS and HFS+ --- the formats this implementation already knows store a mode --- and refused elsewhere with kal_err_not_supported. Recorded as the mode's execute bits: setting ORs in the read bits shifted down, clearing drops all three. A directory is kal_err_is_directory; the enquiry fills the field only for a regular file on a claiming volume and only when the caller's self_size reaches it. Version 0.13.0, openkal = "0.13.0". Comments carry no emoji throughout (21 files, comment and doc text only).
|
`the numbers this kernel serves (macos-15-intel)` failed by timing out at 15 minutes (`##[error]The operation was canceled.`, orphan `served` process killed). This is not caused by this PR's `fchmodat` probe row: the same job, same failure mode (15m0s/15m timeout, `served` orphan-killed), already fails this way on `main` itself --- e.g. run 33084532009, job 98560446281, from 20 days ago, well before this branch existed. `gh run list --workflow=numbers.yml` shows the whole workflow has been reported `cancelled` on every push since 0.5.0. The probe most likely responsible is the pre-existing `select` row (`{ "select", 93, 0, 0, 0, 0 }`): `select`'s fifth argument (the timeout) is never passed by this harness, and on the Intel runner the leftover register apparently resolves to a pointer the kernel blocks on indefinitely, where the arm64 runner happens to return immediately. All jobs this PR's own diff touches passed, including the required `conformance (macos-14, llvm@20.1.7)` job (190 held, 0 did not hold, 3 not observed) and `the numbers this kernel serves (macos-14)`, which confirms `fchmodat` = 467 is served correctly on real hardware. `the kernel's numbers (macos-15-intel)` (the separate table-reading job) also passed. |
The probe passed nfds of zero and no fifth argument, so select read a timeout from whatever the register held. Where that was null the call waited for ever and the job ran into its fifteen-minute limit on macos-15-intel, on main as on every branch. nfds of -1 is refused with EINVAL before a timeout is read.
1 participant
Summary
kal_process_spawnreportedkal_okand a handle for a start that did not happen: the copy calledexecveand thenexit(127), and the parent had no channel to the failure --- a name that does not exist, a directory, or a non-executable file all came back indistinguishable from a program that ran and returned 127. Ported openkal-linux's exec-report pipe onto this kernel's two-registerpipe_pair, with close-on-exec set on each end (nopipe2here) and both ends lifted above3 + grant_countwith the atomicF_DUPFD_CLOEXEC(67 on this kernel; added tosrc/sys.h) so the copy's own placement cannot close them. A failedfchdirorexecvein the copy is now reported through the pipe; the parent reaps the copy and returnstranslate(errno).ENOEXEC(8) now maps tokal_err_not_program.kal_fs_set_executable_atandKAL_INFO_EXECUTABLE, answered on APFS and HFS+ (the formats this implementation already recognises as storing a mode) and refused elsewhere withkal_err_not_supported. Semantics match openkal-linux: set ORs in the read bits shifted down, clear drops all three execute bits; a directory iskal_err_is_directory, a non-regular-file iskal_err_invalid; the enquiry fills the field only for a regular file on a claiming volume and only when the caller'sself_sizereaches it.openkal = "0.13.0"; README snippet versions updated to match.git diff --statand a manual scan).fchmodatrow to.github/workflows/numbers.yml's syscall probe, alongside the existing entries this workflow already measures on real macOS runners.Template: openkal-linux's 0.13 port (commit
51372fd, branchopenkal-0.13). Specification:mcpplibs/openkalPR #33 (branchopenkal-0.13), read together withopenkal-musl/.agents/docs/2026-09-04-issue28-item3-start-failure-and-error-vocabulary.md§3.1.Verification
No macOS machine is available locally, so full conformance can only run on this repository's own CI (
macos-14runner). What was done locally instead:src/*.cpp(touched and untouched) compiles cleanly with Clang,-conly, for botharm64-apple-macos14andx86_64-apple-macos13--- the same freestanding, no-SDK compile the repository's own "other architecture" CI step performs --- against the realopenkal-0.13specification headers (a local checkout ofmcpplibs/openkalat that branch). Only pre-existing, unrelated warnings remain (src/unwind.cpp, array-comparison deprecation, untouched by this change).mcpp build --target aarch64-apple-darwinwas not attempted: this package's own CI anddocs/24-openkal-cross.mdboth establish that a macOS target is reached by locating the SDK throughxcrun, which exists only on a macOS host; there is no cross-SDK path from Linux for this platform today. Given the host's local disk was also down to ~4.5G free during this session, no toolchain/module build was attempted that risked exhausting it.tests/conformance_process_task.cppwas checked by inspection: it locates realtrue/false/shbefore spawning them and never spawns a name it expects to be absent, so the new "started nothing is not kal_ok" behaviour does not conflict with its existing observations.Test plan
macos-14,llvm@20.1.7): conformance (full + optional), surface, independence, this package's own test suites (dev + release), other-architecture compile.gh pr checks --watchand iterate on any failure; report back conformance counts from the macOS job log.