Skip to content

feat: openkal.random on getrandom(2) - #6

Merged
Sunrisepeak merged 3 commits into
mainfrom
feat/openkal-random
Aug 24, 2026
Merged

feat: openkal.random on getrandom(2)#6
Sunrisepeak merged 3 commits into
mainfrom
feat/openkal-random

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

内核自己的调用,而不是 /dev/urandom 那个设备要描述符,描述符要路径,而能力型文件系统刻意不发绝对路径——那是模型在工作。并且一个还没有文件系统的程序仍然有这个调用。

两张系统调用表各加一条:x86_64 = 318,aarch64 = 278。

⚠️ 不设 GRND_NONBLOCK,而这正是 BLOCKING 那一位所报的。 设它会把等待变成短读,而本接口没有「部分成功」这个状态。

⚠️ 失败时缓冲区不恢复——契约如此。恢复它会迫使每次成功的调用都为那一次失败保留副本。

实测:两次 fill 不同字节,props = 1。依赖 mcpplibs/openkal#8

⭐ **内核自己的调用,而不是 `/dev/urandom`。** 那个设备要一个描述符,
描述符要一条路径,而能力型文件系统刻意不发绝对路径 —— 那是模型在工作。
并且一个还没有文件系统的程序仍然有这个调用。

两张系统调用表各加一条:x86_64 = 318,aarch64 = 278。

⚠️ **不设 `GRND_NONBLOCK`,而这正是 `BLOCKING` 那一位所报的。** 不设它,
调用会等到熵池播种完成 —— 在一台刚启动几秒的机器上是真的等待。设它则把
等待变成短读,而本接口没有「部分成功」这个状态,所以等待被保留并在能力字里
被命名。

⚠️ 失败时缓冲区不恢复,而契约就是这么说的:失败的填充留下未指定内容而非
原内容。恢复它会迫使本函数保留一份入参副本 —— 每次成功的调用都为那一次
失败付这个代价。

短返回是内核的(`getrandom` 单次上限 32 MiB),循环是把它变成本接口承诺的
「全有或全无」。

`props = BLOCKING`,不含 `HARDWARE`:读的是内核的池,而池是否由硬件源播种
不是这个后端能观察的。

实测:两次 fill 返回不同字节,props = 1。
规范新增 `openkal.random`,版本升到 0.7.0。CI 的版本同步门要求实现与规范
同步声明 —— 它的诊断说得很准:「Nothing is wrong with either; they are not
in step.」
The branch carried 0.5.3, which is the version on `main` and the version
already in the index. Following openkal 0.7.0 changes what this package
declares, and on two of these repositories it also adds an interface, so
the content behind that number is no longer the content published under
it.

openkal takes a minor bump for a new interface and an implementation
following it takes a patch bump --- the shape of 0.5.2 → 0.6.0 with
0.5.2 → 0.5.3 beneath it.
@Sunrisepeak
Sunrisepeak merged commit e328ba1 into main Aug 24, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant