6.8 KiB
lk — 开工前的逐文件清单
头
b6293957。CONTRACT-P6.md§8.5 要求lk在开工前发布这份清单，理由是早先一份草案的棘轮基线 差了三倍，而装在错误数字上的棘轮第一次 CI 就会因为和泄漏无关的理由变红。 全部计数由grep -rn -E在本头机械产出，口径写在每节标题下。
A 纯度门棘轮基线：Transport/ 之外的缝标识符
口径：<标识符>，排除 MobileGL/MG_Remote/Transport/ 自身。lk 之后这些必须只出现在 Transport/ShmLink.* 与传输自己的测试里。
| 文件 | 类别 | 合计 | 明细 |
|---|---|---|---|
MG_Test/Wire/SessionTest.cpp |
test | 55 | RingControl×16 ReplySlotPool×10 SessionSegments×9 RingProducer×4 RingConsumer×4 SessionConsumer×4 EventRingConsumer×3 SessionProducer×3 EventRingProducer×2 |
MG_Test/Wire/RingTest.cpp |
test | 28 | RingControl×11 RingProducer×9 RingConsumer×8 |
MG_Remote/Client/ClientSession.cpp |
prod | 26 | RingControl×7 EventRingConsumer×7 RingProducer×5 SessionProducer×4 ReplySlotPool×2 SessionSegments×1 |
MG_Remote/Wire/PipeWireCodec.h |
prod | 19 | RingControl×11 RingProducer×6 RingConsumer×1 SessionConsumer×1 |
MG_Test/Wire/PipeWireCodecTest.cpp |
test | 19 | RingProducer×7 RingConsumer×6 RingControl×5 SessionConsumer×1 |
MG_Remote/Server/ServerSession.cpp |
prod | 17 | RingControl×4 RingConsumer×4 EventRingProducer×3 SessionConsumer×3 ReplySlotPool×1 SessionSegments×1 SessionProducer×1 |
MG_Remote/Client/ClientSession.h |
prod | 14 | RingControl×3 SessionProducer×3 RingProducer×2 ReplySlotPool×2 EventRingConsumer×2 SessionSegments×2 |
MG_Remote/Wire/PipeWireCodec.cpp |
prod | 14 | RingControl×6 RingProducer×4 RingConsumer×3 SessionConsumer×1 |
MG_Test/Wire/ServerLoopTest.cpp |
test | 13 | RingControl×4 RingProducer×3 EventRingConsumer×2 ReplySlotPool×1 SessionSegments×1 SessionProducer×1 SessionConsumer×1 |
MG_Remote/Server/ServerLoop.cpp |
prod | 12 | SessionConsumer×6 RingControl×2 RingConsumer×2 RingProducer×1 EventRingConsumer×1 |
MG_Remote/Server/ServerSession.h |
prod | 11 | EventRingProducer×3 RingControl×2 RingConsumer×2 SessionSegments×2 SessionConsumer×2 |
MG_Remote/Server/PipeApplier.cpp |
prod | 5 | SessionConsumer×3 RingControl×1 ReplySlotPool×1 |
MG_Remote/Server/PipeApplier.h |
prod | 3 | RingControl×2 SessionConsumer×1 |
MG_Test/Wire/RemoteClientTest.cpp |
test | 3 | ReplySlotPool×3 |
MG_IntegrationTest/Harness/WireLedgerChecks.h |
test | 2 | RingProducer×2 |
MG_Util/Metrics/PipeStats.h |
prod | 2 | RingProducer×1 SessionProducer×1 |
Config.h |
prod | 1 | RingProducer×1 |
MG_IntegrationTest/Harness/SplitRuntimePeek.cpp |
test | 1 | RingProducer×1 |
MG_IntegrationTest/Harness/SplitRuntimePeek.h |
test | 1 | RingProducer×1 |
MG_Remote/Client/EmitTables.cpp |
prod | 1 | SessionProducer×1 |
MG_Remote/Client/EmitTables.h |
prod | 1 | ReplySlotPool×1 |
MG_Remote/Client/GpuWritePending.h |
prod | 1 | RingProducer×1 |
MG_Test/Wire/InProcessTransportTest.cpp |
test | 1 | RingControl×1 |
合计：生产 127 / 测试 123，共 250 处，分布在 23 个文件。
B 重组影响面：control.<字段> 成员访问
口径：(control|m_control|ctrl)(->|.)<字段>，七个字段 = 四个 watermark + submittedSeq + 两个 event 标志。
这是把 watermark 组变成具名 LinkProgress 成员后必须逐处改写的集合。
| 文件 | 类别 | 处数 |
|---|---|---|
MG_Remote/Transport/Ring.cpp |
transport | 14 |
MG_Test/Wire/RingTest.cpp |
test | 10 |
MG_IntegrationTest/Harness/SplitRuntimePeek.cpp |
test | 5 |
MG_Remote/Wire/PipeWireCodec.cpp |
prod | 4 |
MG_Remote/Client/ClientSession.cpp |
prod | 2 |
MG_Remote/Server/ServerLoop.cpp |
prod | 2 |
MG_Test/Wire/PipeWireCodecTest.cpp |
test | 2 |
MG_Remote/Server/ServerSession.cpp |
prod | 1 |
MG_Test/Wire/SessionTest.cpp |
test | 1 |
合计 41 处（传输内 14 / 生产 9 / 测试 18）。
C 实际结果（重组落地后补记）
两个口径在本文里曾经打架：表 B 的 41（受体限定为 control|m_control|ctrl）与
99649a90 提交信息里的 44（受体不限）。以表 B 的口径为准，差额是三处受体不是
控制页对象的匹配；而实际改写时受体集合还要再宽一档，因为测试里普遍写作
session.Control()->appliedSeq / owner.CmdControl()->appliedSeq。
最终改写：库 15 处 + 测试 58 处 = 73 处（按 re.subn 计，一行可含多处）。
"开集成测试构建"的真正理由不是计数，是守卫：MG_IntegrationTest/Harness/SplitRuntimePeek.cpp
的五处改写躲在 #if defined(MGITEST_SPLIT_RUNTIME_PEEK) && !defined(__ANDROID__) 后面。
本轮用 red-once 证明了它确实在编译——往守卫体内塞一个未声明标识符，构建变红：
SplitRuntimePeek.cpp:99:13: error: use of undeclared identifier 'MGITEST_DELIBERATE_RED_ONCE_PROBE'
差点踩坑的一处：SplitRuntimePeek.h:77 另有一个结构体同样有 appliedSeq 字段，
而 SplitRuntimePeek.cpp:146 一行里两个都在——state.appliedSeq = control->appliedSeq.load(...)。
不限定受体的改写会静默改坏左边，MagmaRunAheadScenario.cpp 的九处访问的正是它（那个文件一行未动）。
D 验收
| 项 | 结果 |
|---|---|
| pull 构建（G1） | 符号 0 增 / 0 删，.text 10822147 不变 |
| split 构建 | 符号 0 增 / 0 删，.text 11681395 不变 |
| 单元测试 | 2326 / 2328，与基线同样的两个环境性失败 |
| 新增静态断言 | 逐条 red-once（下表） |
口径说明：上面的 .text 是尺寸不是字节。字段偏移变了，所以指令里的立即数变了，
但代码尺寸没变。另外这套数字用的是 clang 22.1.6 且关闭 test/benchmark，与路线图记录的
P5f 基线（.text 10806051）不可比，只能做"本包前 vs 本包后、同工具链"的比较。
断言的 red-once
| 扰动 | 结果 |
|---|---|
交换 LinkProgress 里 retiredSeq 与 completedFrameSerial |
红：LinkProgress field order: retiredSeq / completedFrameSerial |
在 LinkProgress 内增加第五个字段 |
红：sizeof(LinkProgress) == 32 |
在 Progress 与 serverEpoch 之间塞一个小成员 |
不红——已具名记在 Ring.h 里 |
最后一行是本轮审查最有价值的产出。serverEpoch 是 alignas(64) 且紧随 Progress 声明，
所以编译器总把它放在下一个 64 倍数处：一个塞在 288 的小成员会落在 Progress 自己那条线上，
而两个断言照样通过，最多能藏 32 字节。审查建议的修法（serverEpoch == Progress + 64）
也抓不住——实测过。Ring.h 的注释现在写明了这一点，因为一道没人能证伪的门比没有门更糟。