企业官网建设流程全解析

• 操作系统
• 嵌入式
• 嵌入式OS

导读

本文基于 doc/Maintenance.md 梳理 Tock（面向微控制器的安全嵌入式操作系统）核心工作组（Core Working Group）的项目维护机制，涵盖长期路线图规划、社区教育与推广、里程碑驱动的发布策略（含分支、标签与版本号管理细则），以及系统调用驱动（Syscall Driver）的稳定化流程。读完本文，你将能够理解 Tock 从「规划—开发—测试—发布—下一个版本迭代」的完整闭环，掌握release-blocker标签、release/$major.$minor分支、annotated tag 与KERNEL_*_VERSION常量的具体用法，并了解如何推动一个系统调用驱动走向「稳定」状态。

一、谁来维护 Tock：核心工作组的角色

Tock 的维护工作主要由 核心工作组（core working group） 负责。根据其章程（Adopted 3/31/2020，Amended 3/01/2024），核心工作组的职责包括：

• 管理并监督 Tock 的代码、文档、测试与发布；
• 定义并传达项目总体目标与方向；
• 将组件与子项目的责任下放给各工作小组，并确保其拥有完成任务所需的人力和资源；
• 协调跨多个工作小组的决策（包括代码、文档、测试和发布）；
• 促进各工作小组之间的沟通与共识。

核心工作组成员是 Tock 仓库中拥有提交（PR 合并）权限的人中的一部分，代表项目的主要视角与核心议题。成员加入需由现有成员提名，并通过修改 doc/wg/core/README.md 的 Pull Request 完成。工作组每周召开电话会议，并在会议后一周内发布详细的会议记录作为对外沟通渠道。

路线图与特性规划（Roadmap and Feature Planning）

Tock 的重大长期规划主要在周期性举办的Tock World研讨会上完成——核心工作组成员和其他利益相关者齐聚一堂，讨论 Tock 新特性的设计与项目总体目标，频率大约为每年一次。除此之外，日常的规划工作则发生在每周的核心工作组电话会议上。

推广与教育（Outreach and Education）

作为一个开源项目，Tock 核心工作组还会定期在学术与专业会议期间举办交互式教程（tutorials），为感兴趣的开发者提供亲手使用 Tock 的实战机会。此外，项目还维护了一本包含多种 Tock 特性自助教程的在线书籍（book.tockos.org），作为持续性的学习资料。

二、Tock 发布策略：里程碑驱动，而非时间驱动

Tock 的发布采用**里程碑驱动（milestone-based）**策略，大致预期每3–12 个月发布一个新版本。其核心流程是：

1. 在发布之前，将一批 issue 打上release-blocker标签；
2. 当计划纳入本次发布的所有release-blockerissue 全部关闭后，创建新的发布分支；
3. 在发布分支上进行测试与验证；
4. 分支稳定后打上发布标签（tag）；
5. 发布后分支不删除，后续修复继续合入该分支，用于打补丁版本（patch release）。

关于release-blocker有一个重要的细节：针对下一个主版本（major version）的 release blocker 不必阻塞小版本（minor version）的发布。也就是说，release-blocker的生效范围是按发布版本类别区分的。

历史背景：Tock 早期曾采用时间驱动的发布策略（目标每两个月发布一次），初衷是让用户更容易安装和追踪 Tock 的变化。但维持这一节奏的维护开销过大，且经常与发布节点上正在开发中的重大特性冲突，因此后来转向了里程碑驱动策略。

发布分支（Release Branches）

一旦所有 release-blocker issue 关闭，即创建新的发布分支，命名格式为release/$major.$minor，例如release/1.4。该分支专用于即将发布版本的测试与验证。分支在发布后不会被删除，后续修复会持续合并进该分支，并用于标记新的补丁版本。

发布标签（Release Tags）

发布测试通过后打上发布标签。Tock 要求发布标签必须是annotated tag（带注释的标签），而不是 GitHub Release 默认创建的 lightweight tag：

git tag -a release-$major.$minor.$patch -m "Release notes..."

• 标签名称格式为release-$major.$minor.$patch；
• 某个 minor 版本的首个发布，patch 号取0；
• 标签应包含与对应 GitHub Release 相同的发布说明（release notes）；
• 使用git tag -a创建的 annotated tag 会被 Git 视为发布质量标签（例如git describe可以识别）。

三、发布任务全流程（Release Tasks）

3.1 发布前（Before the release）

发布前的准备工作包括：

1. 决定本次发布应纳入哪些特性；
2. 在相关 issue 和 Pull Request 上标记release-blocker标签；
3. 开启一个标题为"Release "的追踪 issue，其中包含：
   • 本次发布的目标列表；
   • 用于测试每块开发板（board）的模板清单（checklist）；
   • 供每位核心工作组成员签核（sign-off）的清单；
4. 持续处理带有release-blocker标签的 issue 和 PR，直至全部关闭。

3.2 发布测试（Release testing）

发布测试由核心工作组成员和各开发板维护者共同执行。测试在分支出来的发布分支上进行，而不是在master上。测试的具体操作流程如下：

1. 选择一块要测试的开发板；
2. 从上一次发布的追踪 issue 中复制该开发板的测试清单，并取消所有勾选；
3. 将复制的清单发布到新版本的追踪 issue 中——这表示你认领了该开发板的测试工作；
4. 增加本次发布你希望额外运行的测试。例如，如果该开发板自上次发布以来新增了 capsule，可相应地为新 capsule 添加测试；
5. 运行测试，每完成一项即在清单中勾选。若测试失败，编辑你在 issue 中的评论，将该测试项标记为X表示失败，并附上失败原因的说明；
6. 对所有失败的测试，要么提交修复 PR，要么开启描述该失败的 issue 寻求帮助。

Tock 刻意不在仓库中维护固定的测试列表，而是采用「上一轮该板卡运行过的全部测试 + 维护者本轮新增的测试」的方式，让测试覆盖随板卡功能演进自然增长。

如果在测试过程中发现 bug 且需要大量修改，可以再打**发布候选（release candidate）**标签。是否需要对所有板卡重新测试，由核心工作组决定。

3.3 打发布标签（Tagging a release）

当以下条件全部满足时，即可打发布标签：

• 所有板卡的测试全部通过；
• 更新了 CHANGELOG.md（该文件按版本记录每个发布的新特性、修复与兼容性说明，例如「New in 2.2」章节记录了约 3900 个 commit、840 个 PR 以及向后兼容性承诺）；
• 将 kernel/src/lib.rs 中的KERNEL_PRERELEASE_VERSION设置为0（表示这是正式发布版本）；
• 更新根目录 Cargo.toml 中的版本号。

3.4 启动下一个版本（Starting the next release）

在分支发布之后立即开始下一轮迭代，操作如下：

• 在master分支上递增 minor 版本号，并将 patch 版本号清零；
• 在根目录 Cargo.toml 中把版本设置为<新版本>-dev（例如当前仓库中的version = "0.2.4-dev"）；
• 在 kernel/src/lib.rs 中更新KERNEL_MAJOR_VERSION、KERNEL_MINOR_VERSION、KERNEL_PATCH_VERSION，并将KERNEL_PRERELEASE_VERSION设为1。

版本号在源码中的落地：Kernel Attributes

版本信息不仅仅是文档约定，它被真实编译进内核二进制。在 kernel/src/lib.rs 中：

• KERNEL_MAJOR_VERSION、KERNEL_MINOR_VERSION、KERNEL_PATCH_VERSION、KERNEL_PRERELEASE_VERSION四个常量当前值分别为2、4、0、1（即当前处于 2.4.0 的预发布开发阶段）；
• 这四个常量被组装进TockAttributesKernelVersion结构体，并通过#[cfg_attr(target_os = "none", unsafe(link_section = ".tock.attr.kernel_version"))]放入链接脚本指定的.tock.attr.kernel_version段；
• 该结构体遵循 Tock Kernel Attributes 格式（tlv_type: 0x0103，tlv_len: 8），供引导加载程序、工具链与应用程序校验内核版本与自身应用的兼容性。

从源码可以看出：KERNEL_PRERELEASE_VERSION为0表示正式发布，非0表示开发版本；应用或工具还可以利用它依赖尚未进入任何发布版本的内核特性。

四、稳定化一个 Syscall Driver（Stabilizing a Syscall Driver）

4.1 稳定化的含义与保证范围

Tock 维护一份**已稳定系统调用驱动（stabilized syscall drivers）**清单，这些驱动实现SyscallDrivertrait，通常位于 capsules 中。稳定化的核心承诺是：

在相同主版本号（major version）的后续内核版本中，Tock 保证不会破坏这些已稳定驱动的接口。

这意味着，使用某个已稳定系统调用驱动的应用程序，在相同主版本的内核上可以继续正常工作。同时，Tock 并不禁止在同一主版本内扩展已稳定接口——允许添加新功能或修复 bug，只要不破坏向后兼容性。

需要特别注意的是：该稳定性保证独立于系统调用接口（即command、allow、schedule等 ABI 本身）的稳定性，两者是不同层面的承诺。

4.2 稳定化流程（Syscall Driver Stabilization Process）

一个驱动（由其driver number唯一标识）的稳定化遵循以下流程：

1. 文档完备：该驱动必须在 doc/syscalls 目录下拥有完整的接口文档（如 00001_console.md、00000_alarm.md 等）；
2. 提出稳定化 PR：Tock 开发者通过创建 Pull Request 提出将某个特定驱动（以其 driver number 和上游 Tock 仓库中的源码标识）稳定化，PR 需要把该驱动移入capsules/corecrate，并在 doc/syscalls/README.md 的稳定化列中标上 ⏰（表示"待观察"）；
3. P-Significant 评审：稳定化 PR 始终被标记为P-Significant，这要求核心工作组支持该稳定化；
4. 四个月观察期：该驱动的接口必须在四个月内保持不变。这段时间可以从稳定化流程开始之前的某个时间点算起；
5. 变更即重置：如果观察期内接口发生变更，等待期重新开始计算。驱动在此期间还必须经过合理的测试；
6. 标记稳定：观察期结束后，在下一次 Tock 主版本或小版本发布时，将 doc/syscalls/README.md 稳定化列中的 ⏰ 更新为该 Tock 发布版本号，即完成稳定化标记。

4.3 稳定化状态的仓库证据

doc/syscalls/README.md 是稳定化状态的权威记录：其中每个驱动表格都带有一列稳定性标记列（该文件头部注释说明 "2.0" 列表示该驱动是否已在 Tock 2.0 发布中稳定化，"✓" 表示稳定）。

以当前仓库为例，已稳定化的驱动包括：

而未稳定化的驱动（如 0x00004 GPIO、0x00010 PWM、0x20000 UART 等）在该列中留空，等待后续版本按上述流程逐步推进。

被稳定化的驱动会进入capsules/corecrate。例如 Console 驱动的SyscallDriver实现位于 capsules/core/src/console.rs，其配套的接口文档为 doc/syscalls/00001_console.md。这种「文档 + 源码 + 稳定化标记」三位一体的结构，保证了稳定化承诺既可被审计（文档与标记可追踪），又可被实现（源码可验证）。

五、维护者的日常工作与协作机制

除发布与稳定化外，核心工作组的日常维护还包括：

• 代码评审：核心组成员需要按比例评审新 Pull Request，确保代码风格与结构的一致性（可参考 doc/CodeReview.md 与 doc/Style.md）；
• 测试参与：成员需在发布前参与 Tock 的测试；
• 设计决策：对重大设计变更提供意见与输入；
• 文档与工具链：项目通过 doc/CodeGoals.md、doc/SecurityProtocol.md 等文档约定长期目标与安全流程，并通过 tools/ 下的 CI、license-checker、qemu-runner 等工具链支撑持续集成与质量保障。

总结

Tock 的维护体系可以概括为三条主线：

1. 规划：通过年度 Tock World 研讨会与每周核心工作组会议确定长期方向；
2. 发布：以release-blocker驱动的里程碑策略，配合release/$major.$minor分支、annotated tag 和「KERNEL 版本常量 + Cargo.toml 版本 + CHANGELOG」三处同步更新的机制，形成可重复、可审计的发布闭环；
3. 稳定化：以「完整文档 + 四个月无变更观察期 +P-Significant评审 + 版本号标记」流程，为用户态应用提供同主版本内的接口兼容保证。

对于想要参与 Tock 维护的开发者，最实际的切入点有两个：一是认领某块开发板的发布测试（复制上一轮清单并逐项验证），二是通过提交稳定化 PR 推动某个尚未稳定的系统调用驱动（如 GPIO、UART）进入capsules/core并完成四个月观察期。这两条路径都完全基于本文所描述的、由 doc/Maintenance.md 定义并在仓库源码中落地的流程。

• 操作系统
• 嵌入式
• 嵌入式OS