feat: getrandom through the interface layer, and a gate for the trees it is built against - #7
Merged
Merged
Conversation
…onsumer looks for it musl 自己的 `src/linux/getrandom.c` 直接发 `SYS_getrandom`。在 Linux 内核 底下时这是对的,在这里是错的:**这个 port 存在的理由就是让每一次请求 经 openkal 到达环境。** dispatch 里加一个 case,转给 `kal_random_fill` —— 与已经在那里的 69 个 系统调用同一条路。⚠️ flags 被忽略:`GRND_NONBLOCK` 要的是短读,而 `kal_random_fill` 没有 部分成功可报。一个会阻塞的环境在 `kal_random_props` 里说这件事。 ──⚠️ 并且 `getentropy` 的声明位置,glibc 与 musl 不同 ──────── glibc <sys/random.h> 声明 getrandom 与 getentropy musl <sys/random.h> 只声明 getrandom;getentropy 在 <unistd.h> 而 libc++ 的 GETENTROPY 分支只 include 前者: random.cpp:52:14: error: use of undeclared identifier 'getentropy' ⭐ 这正是 `port/include/` overlay 存在的问题类型 —— 消费者问的是 「这是哪个操作系统」并假定那个系统的 C 库,而这里的 C 库是 musl。 `port/include/sys/random.h` 用 `#include_next` 取回 musl 那份, 再补上那一行声明。⚠️ **只加声明,别的什么都不加。** 定义仍是 musl 的 `src/misc/getentropy.c`, 未经修改;本文件纠正的是消费者去哪里找这个名字。两处都声明正是 glibc 的做法, 也是消费者所针对的。 实测:`getentropy` 返回 0,两次调用字节不同 —— 整条链 `std::random_device → getentropy → getrandom → kal_random_fill → 后端` 全程走接口层。
规范新增 `openkal.random`,版本升到 0.7.0。CI 的版本同步门要求实现与规范 同步声明 —— 它的诊断说得很准:「Nothing is wrong with either; they are not in step.」
Pointing a manifest at a working tree removes the one check that would
otherwise happen: the resolver never sees a version requirement, so a
tree of any age satisfies it. `fetch` falls back to the default branch
where a repository has no branch of this name, which is right — most
branches here have no counterpart — but a change spanning two
repositories is then built against whichever half is on `main`.
That fallback produced a failure naming the wrong thing. This package's
branch was `feat/getrandom-through-openkal` and the specification's was
`feat/openkal-random`, so openkal 0.6.0 was supplied to a manifest
asking for 0.7.0 and five jobs reported:
port/src/okm_syscall.c:27:10: fatal error: 'openkal/random.h' file not found
A missing header reads as a mistake in this package. The mistake was
that the two halves were not in step, and that is what this says.
A hard failure is also the only safe answer here: had the
specification's change been additive, the same mismatch would have
passed while testing a specification nobody was reviewing.
Measured against the requirement this package states, `openkal = "0.7.0"`:
tree 0.6.0 → exit 1, "they are not in step"
tree 0.7.0 → exit 0
tree 0.7.4 → exit 0 a patch may move forward
tree 0.8.0 → exit 1 below 1.0 a minor bump is a breaking change
The branch is renamed to the name the rest of this change uses, which is
what makes the fetch find its counterpart.
The declarations pointed at versions published before openkal 0.7.0, and under caret rules those older versions still satisfy the requirement. A project resolving this package could therefore be handed an implementation declaring openkal 0.6.0 alongside a specification at 0.7.0, and 0.6.0 and 0.7.0 do not resolve together below 1.0. Naming the new versions is what makes the resolver reach the implementations this release was tested against.
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.
SYS_getrandomis forwarded tokal_random_fillrather than issued as a system call, so a musl built on openkal has an entropy source on every system openkal has an implementation for.port/include/sys/random.hdeclaresgetentropywhere a consumer written against glibc's header layout looks for it. musl declares it in<unistd.h>; the overlay adds a declaration and nothing else.Also gates the working trees this package is built against — see the commit; it converts a misleading "file not found" into a statement that two halves of one change are not in step.
Supersedes #6, which GitHub closed when the branch was renamed to the name the rest of this change uses.