内核架构（Kernel）

系统级定义（System Definition）

Kernel 是 HRTOS 中唯一的全局调度控制器（Global Control Executor）， 其作用不是执行任务，而是定义系统执行的“可运行空间”。

从形式化角度：

Kernel（内核） = {调度 + 抢占 + 时序控制 + 边界约束执行}

即：Kernel 决定系统“允许发生什么”，而不是“发生了什么”。

Kernel 之所以被视为全局控制器，是因为它掌握三个关键判定：何时允许抢占、何时允许恢复、何时必须阻塞。任务只是 CPU 时间的消费者，真正定义执行合法性的，是内核在每个调度点上给出的状态迁移规则。

在工程实现里，这意味着 Kernel 需要同时维护 ready bitmap、延时队列、中断嵌套计数、超时计数器以及系统对象状态。当这些状态在一个统一控制面内收敛时，系统才具备可分析的执行链路。

这也是为什么 Kernel 控制对象通常比应用对象少但更关键：TCB、ready set、tick source、wait list 和 interrupt nesting state 共同定义了系统的实时骨架。

进一步说，Kernel 不是把所有功能都收进来的“系统中心”，而是把所有关键状态都收拢到可证明边界内的“收敛中心”。任务执行、超时到期、ISR 退出、同步对象释放，这些看似分散的行为最终都必须回到同一套内核状态转换规则中，才能保证系统在最坏情况下仍然可以解释。

在项目交付阶段，内核定义页往往还是时序评审的入口。架构师需要回答哪些状态属于内核私有控制面，驱动工程师需要回答哪些事件会迫使系统立即重调度，验证工程师则需要回答这些事件在极端负载下是否仍然存在稳定上界。

• 控制对象必须有限且可枚举，避免在关键路径上出现不可追踪的隐式状态。
• 内核入口必须统一，避免中断路径、系统调用路径和超时路径形成多套决策语义。
• 状态转换必须可回放，确保 tracing 结果能够和设计文档一一对应。

Kernel 控制模型（Control Model）

Kernel 的运行不是线性执行，而是一个闭环控制系统：

事件 → 控制决策 → 调度 → 执行 → 状态迁移 → 再次进入

每一次系统行为，都会重新回到 Kernel 进行再决策。

这个闭环的关键不是“循环次数”，而是每次循环的决策深度必须可界定。一次中断退出、一条系统调用返回、一次信号量释放，本质上都会触发同样的内核入口逻辑，从而把分散的事件重新折叠回统一的调度模型。

因此内核控制模型可以理解为一个实时状态机：输入是中断、超时和资源事件，输出是任务状态迁移与 CPU 所有权变化。只要状态机转移边界清晰，系统最坏响应时间就可以被分段分析。

在 tick 驱动系统里，时钟中断会周期性把所有超时对象重新带回控制回路；在 tickless 系统里，内核则必须根据最近到期事件重构下一次唤醒点。两种实现不同，但都要求控制模型对时间推进保持单一解释。

这也是为什么内核路径常被要求避免递归式复杂逻辑。控制模型越像固定深度的有限状态机，系统越容易在实机上复现实验室里的时序结论。

从实现细节看，Kernel 控制模型至少要稳定维护四类核心变量：当前运行者、全局就绪集合、延时/等待集合以及中断嵌套上下文。任何一个变量如果在不同入口上采用不同的更新顺序，都可能造成“逻辑一致、时序失真”的隐蔽问题，例如任务已经被唤醒，但由于延时链和 ready set 更新不同步，真正得到 CPU 的时刻被额外拖长。

工程上常见的优化思路不是给控制模型叠加更多捷径，而是把重负载操作后移。比如在 ISR 中只完成最小状态记录，在中断尾部只做是否抢占的判定，把复杂协议解析、日志记录和统计汇总放到线程上下文中执行，这样内核控制面就能长期维持短路径和固定分支深度。

• 所有入口都必须遵守统一的状态更新顺序，否则 worst-case analysis 很难成立。
• 临界区的目标不是“绝对安全”，而是把共享状态保护在有界时间窗口内。
• 延迟处理的价值在于把非必要工作迁出控制面，而不是把复杂度隐藏起来。

核心结构

这四个入口页分别从职责、结构、执行链路和边界条件四个角度展开同一个内核主题。把它们拼在一起，可以得到从“内核是什么”到“内核如何保证确定性”的完整解释。

从学习路径上看，这个结构并不是简单目录，而是一套由粗到细的分析顺序。总览页回答“内核控制什么”，结构页回答“内核由哪些稳定对象构成”，流程页回答“这些对象如何在时间线上协同”，边界页则回答“哪些行为一旦进入系统就必须被拒绝或隔离”。

如果把它映射到工程活动，架构设计通常先完成职责和边界定义，再落实为稳定的数据结构和调度路径，最后通过 tracing、压测和 worst-case 预算验证流程是否真的闭合。只有这四个视角共同成立，内核文档才不只是说明书，而是验证资产。

• 总览强调控制平面语义，帮助界定内核在系统中的权责范围。
• 结构强调对象所有权和入口关系，帮助避免职责重叠与共享状态失控。
• 流程强调时间链路，帮助定位响应延迟、中断尾部恢复和上下文切换成本。
• 边界强调不可接受行为，帮助把系统限制在可调度、可验证的空间内。

系统关系

中断事件（Interrupt） → 进入内核控制域 → 调度决策点（Scheduler Decision） → 任务选择（基于优先级与时间约束） → 上下文切换执行 → 资源访问与权限仲裁 → 系统状态迁移（Running / Ready / Blocked） → 重新进入内核调度循环

该执行链路的本质是：系统在每一次中断或事件触发后，重新回到内核进行确定性收敛， 从而保证实时系统行为始终处于可预测状态。

从执行链路上看，中断负责把外部世界带入系统，调度器负责做时间选择，内核负责实施选择，IPC 与内存子系统负责在选择之后维持数据一致性和资源可达性。Kernel 位于这条链路中央，因此它既是事件汇聚点，也是确定性扩散点。

典型案例是伺服驱动器中的周期控制任务：定时器中断触发采样，内核在中断尾部判断控制任务就绪，调度器执行抢占，控制任务完成计算后通过消息队列唤醒输出任务。整个链路是否满足周期约束，最终取决于内核控制面是否稳定。

对复杂项目而言，这条关系链还决定了调试顺序：先确认事件是否按时到达，再确认内核是否及时收敛，再确认数据路径是否完成后续传播。顺序一旦颠倒，很容易把结果问题误判为原因问题。

这也是内核文档需要同时覆盖结构图与执行链的原因。只有两者对应起来，控制逻辑才不会停留在概念层，而能直接映射到可观测的系统行为。

从模块关系分析的角度看，Interrupt 提供事件入口，Scheduler 提供选择逻辑，IPC 提供阻塞与唤醒通道，Memory 提供访问边界和对象寿命约束，而 Kernel 则负责在每次状态变化后重新收敛这些输入。没有这种收敛，模块之间就会形成各自为政的局部最优，最终在高负载场景下表现为全局失稳。

典型案例是双环控制系统中的“采样中断 -> 电流环任务 -> 位置环任务 -> 总线上报任务”。如果内核在中断尾部无法稳定判断抢占，位置环任务又通过 IPC 链式唤醒多个下游对象，那么轻微的优先级设置偏差就会被放大成周期抖动。系统关系页的价值就在于提醒开发者：真正需要控制的不是单个模块，而是模块串联后的端到端执行链。

• 设计时应优先检查中断到任务恢复的路径是否最短，而不是先优化后台处理吞吐。
• 验证时应同时观测 ready set 更新、上下文切换和共享资源访问，避免只盯单点时延。
• 维护时应把新增功能映射回现有执行链，确认它不会引入新的无界阻塞或旁路调度。

在实际项目中，Kernel 架构页还常被用作接口裁剪依据。凡是会直接影响运行权、阻塞关系或时间基的能力，都应优先靠近内核统一实现；凡是只影响业务语义、统计结果或可延后处理的能力，则应尽量留在外围任务层。这样做可以防止“为了方便”把越来越多的不确定逻辑吸进内核主路径。

边界条件分析也应在这一层完成。例如：系统是否允许在中断上下文创建对象，是否允许后台任务直接修改调度参数，是否允许驱动绕过 IPC 直接唤醒多个任务。只要其中某一项答案模糊，Kernel 作为统一控制面的角色就会被削弱，最终让系统在不同模块中出现多套隐性控制逻辑。

• 架构上应优先把“控制权相关能力”内聚，把“业务负载相关能力”外移。
• 文档上应明确哪些操作只能由内核发起，哪些操作只能通过内核网关完成。
• 验证上应覆盖高频中断、批量唤醒和资源竞争并发出现的组合场景。

如果这一页能够让读者最终形成一个稳定判断标准，那就是：任何会改变 CPU 所有权、阻塞关系或时间推进方式的行为，都应该先回到内核架构层解释清楚，再决定是否值得被纳入主路径。