docs: 四项未完成事项的方案 - #471
Merged
Merged
Conversation
对象是 2026-08-20 那批实施之后仍然敞开的四件事。每一项给出修法、判据与 代价,四项之间无依赖,可并行也可只做其一。⚠️ **第 0 节纠正一处记录。** 前一份文档与若干提交信息写着「Windows 的 LLVM 载荷不带 libc++ 头,已由 CI 测量」。该测量不成立:那一步打印的 `payload: .../xim-x-llvm/*/` 里 glob **没有展开**,说明我在脚本里拼的 home 路径在 Windows 上就是错的。它测到的是「路径猜错了」,不是「头不在」。 已经成立的只有一条:该行死于 `'algorithm' file not found`,即 clang 解析 到了而头不在 mcpp 给出的 include 路径上。载荷内容至今没被列出过,所以 第 2 节的第一步是补测量,而不是直接动载荷。 四项的结论: **Windows libc++** —— 选「加进现有载荷」而不是「独立成包」,理由是体积: 头加导出表 xz 压缩后 **0.9 MB**,而载荷解包后 893 MB;独立成包所解决的 问题在这里不存在,却会引入一条索引表达不了的跨包版本约束。且不改 Windows 宿主的默认 STL。 **feature 源不一致** —— 三次修法全部被测量证伪的记录写进文档。三次失败 指向同一结论:判据不是「glob 字符串在不在 base 里」,而是「base 的任何一条 glob 是否匹配这条 feature glob 匹配的文件」,需要 glob 展开。给出引擎内 展开与清单显式表达两条路线,建议前者,因为后者在每个包补键之前不修复任何 现存的包。 **openarch 的四个接口** —— 按「哪一个最可能证伪接口」排序而非按完整性。 ⭐ 时钟那一条建议先作为**调研**:riscv 的可移植时钟要经 SBI,若如此它属于 openkal 的实现方而不是 openarch,这会改变分层——调研比实现便宜得多。 **x86_64 裸机** —— QEMU 可从源码构建且可只构建单目标,难点在五个宿主 而非构建本身,其中 Windows 最难。更省的路是沿用 xPack 公开的构建脚本, 只换 `--target-list`。分三阶段,阶段一只做 linux x64 供 openkal-uefi 用, 但**不破例收录**——收录门槛是五个宿主,破例一次门槛就降成注释。 三项与外部有关,排期要当外部依赖:载荷打包脚本不在本仓库、qemu-x86 要进 xim-pkgindex、五宿主构建需与 xPack 协调。
**⚠️ 收回一条论证。** 第一版反对把 libc++ 头独立成包,理由是「索引没有表达 跨包版本约束的机制」。那个前提是错的:一条带版本要求的依赖边**就是**那个 机制,而 `std-freestanding` 自己已经在用(`[feature-deps]` 里的 `^0.2.0`)。 我把「描述符里的注释」与「依赖边」混成了一件事。 收回之后取舍**相反**:改选独立成包。决定性的不是体积(0.9 MB 对 893 MB 两边 都不痛),而是另外两点——它是我们自己能做完的(载荷打包脚本不在本仓库), 并且它把这件事放回了本次实施已证明正确的位置:**目标需要什么由目标解析, 而不由宿主的编译器顺带提供**,与 C 库经 `[target.X].sysroot` 解析同构。 顺带回答了「freestanding 支持应当与标准库无关」:拆成接口 / 配置 / 头从哪来 三层之后,只有中间一层与实现有关,而且很小(libc++ 合成 `__config_site`, libstdc++ 一个宏、实测 29/34)。Windows 的问题在第三层,与用哪个标准库无关。 **openarch 第 3 节改为已完成**:trap 与 cpu 两个接口连同两个后端已实现 (0.3.1),并补上三层目录树(abi / spec / backends)与它逼出的接口变化。 ⭐ 记下门槛产出的第三条发现:`trap_frame` 必须带 `instr_len`——rv64gc 的 `c.ebreak` 是两字节,按 4 推进会落进下一条指令中间,而 aarch64 只有一种指令 宽度、永远暴露不了它。 **x86_64 采纳「先在临时 PR 的 CI 上跑通五条腿再收录」**:GitHub 托管的 runner 恰好覆盖本索引服务的五个宿主,可以在同一个 PR 的矩阵里一次跑出来。构建失败 在那里只是一个红叉,而不是一个已发布却装不上的包;而且它把 Windows 那条最难 的腿的风险前置。
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
2 participants
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.
对象是 2026-08-20 那批实施之后仍然敞开的四件事。每项给出修法、判据与代价。
前一份文档写着「Windows 的 LLVM 载荷不带 libc++,已由 CI 测量」。该测量不成立:那一步打印的
payload: .../xim-x-llvm/*/里 glob 没有展开,说明我拼的 home 路径在 Windows 上就是错的。已成立的只有「构建死于'algorithm' file not found」。载荷内容至今没被列出过。四项结论
--target-list更省。分三阶段,阶段一不破例收录纯文档。