0.14.0 --- a start that is not a program reports ENOEXEC, and chmod can grant the one bit openkal now answers - #35
Merged
Merged
Conversation
…an grant the one bit openkal now answers openkal 0.13 closed two gaps a consumer met from opposite sides (issue #28). `okm_errno` had no case for `kal_err_not_program`, so `posix_spawn` of a file that exists, is executable, and is not a program fell to the default arm and reported EIO --- a device failure that never occurred --- instead of ENOEXEC, the condition every host this port targets reports natively. It now does, and no `/bin/sh` fallback is added for it: musl's own `execvp` has none either (musl/PATCHES.md already declines the analogous case for `:`). `chmod`, `fchmodat` and whatever `std::filesystem::permissions` reaches now route to `kal_fs_set_executable_at` for the one request this port can honestly grant: the execute bits, set to match the read bits this port already reports, or cleared. A request that changes anything else --- the read or write bits, which are always uniform across the three classes here --- is refused with ENOSYS rather than rounded to a mode `stat` will not then show. A no-op equal to the mode already reported succeeds even where the volume declines KAL_FS_PROP_EXECUTABLE. `fchmod` stays ENOSYS unconditionally: this port keeps no name for an open file to hand the call. `stat`/`fstat`/`fstatat`/`statx` and `access(X_OK)` read the same field back. examples/subprocess asserts both, on every row, and failed against the unmodified port before this change. README's limits table states what changed and versions it per implementation, and adds the ecosystem design record's R1 and R2 as limits of their own: one C runtime and one C++ runtime per image, and a context a platform library creates has no C library state. Tracked docs and comments are stripped of emoji. Carries openkal 0.13.0, openkal-linux 0.13.0, openkal-macos 0.10.0 and openkal-windows 0.8.0.
Name resolution by name fails there: musl's resolver reads /etc/resolv.conf through this port's filesystem layer, and openkal defines no name resolution (SPEC.md clause 3.4, clause 11 item 5) for a nameserver list Windows keeps where this port cannot read it. getaddrinfo reports EAI_AGAIN rather than guessing one; a numeric address is unaffected. Measured under Wine with openkal-windows 0.7.4 / this package's 0.13.5. And a C program linking this package directly for x86_64-windows-gnu fails to link on three compiler-rt builtins this package carries no archive for; a C++ program through openkal-llvm-runtime receives them with the rest of the runtime it names. Measured with mcpp 2026.9.17.2, including the fix for mcpp#662. Neither is addressed in this change.
… position, and the install lines A chmod that would change a directory's execute bits reached kal_fs_set_executable_at, which refuses a directory, and reported EISDIR; it now reports ENOSYS like every other change this port cannot express, and the subprocess probe asserts it. The comment in fill_kstat claimed stat and access(X_OK) read an unanswered position the same way; they do not, and did not before 0.14.0 (stat: no execute bits; access: yes), which the comment and the README row now state. README install lines name 0.14.0 and runtime 0.10.0, and the carried-by table gains the 0.14.0 row.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
openkal 0.13 closed two gaps a consumer met from opposite sides (issue #28):
okm_errnohad no case forkal_err_not_program, soposix_spawnof a file that exists, is executable, and is not a program reportedEIO(a device failure that never occurred) instead ofENOEXEC. It now does; no/bin/shfallback is added for it, matching musl's ownexecvpand the existing decision inmusl/PATCHES.md.chmod/fchmodat(and whateverstd::filesystem::permissionsreaches) now route tokal_fs_set_executable_atfor the one request this port can honestly grant: the execute bits, set to match the read bits this port already reports, or cleared. Anything else is refused withENOSYSrather than rounded to a modestatwill not then show. A no-op equal to the mode already reported succeeds even where the volume declinesKAL_FS_PROP_EXECUTABLE.fchmodstaysENOSYSunconditionally (no name to hand the call).stat/fstat/fstatat/statxandaccess(X_OK)read the same field back.examples/subprocessasserts both on every CI row, and fails against the unmodified port. README's limits table is rewritten for permission bits, whether a file may be executed, and the 127 claim, and gains the ecosystem design record's R1/R2 as limits (one C runtime and one C++ runtime per image; a context a platform library creates has no C library state).Tracked docs and comments are stripped of emoji.
Carries
openkal0.13.0,openkal-linux0.13.0,openkal-macos0.10.0 andopenkal-windows0.8.0 (features unchanged), package version 0.14.0.Test plan
mcpp buildagainst../openkaland../openkal-linuxonopenkal-0.13(viatools/working-trees.sh)examples/subprocessprobe: red against the unmodified port (3 failures: ENOEXEC not reported, chmod no-op refused), green after this changeexamples/posix,examples/surface,examples/net,examples/identifiersprobes still passopenkal-macos/openkal-windowsbranches also being ready