openkal 0.14.0 and the eight packages of its wave: register descriptors - #442
Merged
Merged
Conversation
The specification's 0.14 adds `KAL_TERM_PASS_CONTROL` to `openkal.terminal`'s mode word and corrects `KAL_VERSION_MINOR`, which every implementation answers `kal_version` with; the four implementations map the position, the two firmware backends follow the version, and openkal-musl routes the terminal ioctls through the interface. openkal 0.14.0 0e0410fb... openkal-linux 0.14.0 331a6524... openkal-macos 0.11.0 576356ea... openkal-windows 0.9.0 27122bef... openkal-emscripten 0.3.0 34067d2a... openkal-uefi 0.8.0 a1c920dc... openkal-opensbi 0.8.0 557a28f7... openkal-musl 0.16.0 8ffa4a2a... Each sha256 is of the GitHub archive of the plain tag, and the GitCode asset is that same file uploaded unchanged --- verified for openkal 0.14.0 by downloading both and comparing. AND THE PARITY LINT IS GREEN AGAIN. `tests/check_platform_version_parity.lua` runs whole-repo and has been failing on `main` since the previous wave: openkal-musl 0.15.0 and openkal-llvm-runtime 0.11.0 were registered under `xpm.linux` and `xpm.windows` and not under `xpm.macosx`, which is exactly the partial bump that lint exists to catch. Both are now present in all three. openkal-llvm-runtime 0.12.0 is not here: it pins openkal-musl exactly, so it cannot be built until openkal-musl 0.16.0 is registered by this change. It follows in its own descriptor update.
It pins openkal-musl exactly, so it could not be built until openkal-musl 0.16.0 was registered by the commit before this one. Its CI is green against that version and the release is published on both mirrors: openkal-llvm-runtime 0.12.0 e009f619...
Sunrisepeak
added a commit
that referenced
this pull request
Sep 20, 2026
…time (#444) tests/openkal/pins.toml moved `runtime` from 0.10.0 to 0.12.0. Below that version no package the pin resolves declares a `[c-abi]` block, so mcpp realises nothing for the target side and the Windows leg compiles as x86_64-w64-windows-gnu with `_WIN32` defined --- the condition every `#ifdef _WIN32` branch in the measured members selects on. Every Windows result recorded under 0.10.0 therefore measures the behaviour the declaration exists to replace rather than the declaration. The descriptors for both packages were already registered (#441, #442) and their two mirrors compared byte for byte before this move: openkal-musl 0.16.0 and openkal-llvm-runtime 0.12.0 each answer the same sha256 from the GitHub archive and the GitCode asset. Co-authored-by: Claude Code <noreply@anthropic.com>
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.
注册 openkal 0.14 波次的九个包，并修好
main上已经红着的平台一致性 lint。注册
0e0410fb…331a6524…576356ea…27122bef…34067d2a…a1c920dc…557a28f7…8ffa4a2a…e009f619…每个 sha256 都是 GitHub 上无 v 前缀标签的 archive 的哈希，GitCode 资产是同一个文件原样上传——openkal 0.14.0 两边都下载比对过，逐字节一致。
openkal-llvm-runtime 0.12.0在第二个提交里：它精确钉住 C 库，要等openkal-musl 0.16.0先被注册才能构建，所以两件事在同一个 PR 里按顺序落。顺带修好的：平台一致性 lint
tests/check_platform_version_parity.lua是全仓库跑的，而main从上一波起就是红的：openkal-musl 0.15.0与openkal-llvm-runtime 0.11.0只注册在xpm.linux和xpm.windows，缺xpm.macosx——正是那条 lint 存在的理由（半个版本升，文件里"能 grep 到"，在缺的平台上报 not found）。两处都补齐了。一个尚未修好的、要记在案的缺陷
openkal-musl 0.15.0与openkal-llvm-runtime 0.11.0在 GitHub 上的标签是v0.15.0/v0.11.0，而描述符里的 GLOBAL 地址按惯例写的是无前缀形式，所以这两个版本的 GLOBAL 地址取不到东西（返回 14 字节的 Not Found）。补一个无前缀标签也修不好：GitCode 上的资产不是 GitHub archive 本身（75803192…对ee953bd8…），两边字节从一开始就不同，而描述符只有一个 sha256。真正的修法是把 GitCode 上那两个资产换成 GitHub 的 archive，而同名资产gtc上传会被拒绝——需要所有者在 GitCode 侧先删除。本波九个包都按惯例发布，GLOBAL 用户用新版本即可绕开。不在本 PR 里的
tests/openkal/pins.toml的runtime仍是 0.10.0：30 个成员的测量按自己的节奏走，本波不动它。