# T-Kernel 与 TOPPERS/ITRON：上下文合法性 与 静态配置

<CORE RULE>
TRON/ITRON 这一系最核心的经验是：

```
同一个服务调用，在不同执行上下文里合法性不同
```

所以看到 `act_tsk` / `sta_cyc` / 设备读写这类调用时，**先恢复"它跑在哪种上下文里"，再谈语义**——只恢复 API 名会得出错误结论。

第二条：这一系**高度依赖静态配置**，**没有普通代码交叉引用的 task/handler 可能来自配置生成**。
</CORE RULE>

## 一、T-Kernel：三种执行上下文

| 上下文 | 特征 |
|---|---|
| **任务部分（task portion）** | 常规任务执行 |
| **准任务部分（quasi-task portion）** | 由**特定任务请求**而运行的处理：能识别发起任务、可定义任务状态迁移、**可以发出会进入等待状态的服务调用**；但有独立的处理器操作模式与栈空间（是 OS 的扩展部分） |
| **任务独立部分（task-independent portion）** | 由**与任务进度无关的因素**激活（外部中断处理程序、时间事件处理程序）：**不存在"当前发起任务"概念**——不能调用会进入等待状态、或隐式指定发起任务的服务调用；**不发生派遣**（延后派遣） |

**服务调用的合法上下文是规范明确规定的**，例如"等待设备请求完成"：任务部分与准任务部分合法，**任务独立部分不合法**。

**设备驱动模型**：

- 设备经 `tk_def_dev` 注册，注册时指定处理函数集合：**openfn / closefn / execfn / waitfn / abortfn / eventfn**
- 这些函数由设备管理调用，**以准任务部分运行**；**必须可重入**，且**不保证互斥调用**——需要互斥时由驱动自己做
- 具体运行上下文细化：open/close 是调用 open/close 的那个任务的准任务部分；**execfn 是调用"读/写起始"的任务的准任务部分；waitfn 是调用"等待"的函数的任务的准任务部分**

**异步请求模型**：

```
tk_rea_dev / tk_wri_dev → execfn（只发起，不等完成，返回）
tk_wai_dev              → waitfn（等待完成）
```

- 完成顺序**不一定等于请求顺序**（取决于驱动），但**处理结果必须与请求顺序保持一致**
- `tk_wai_dev` **只等待调用时刻正在处理的那些请求**；之后发出的请求不在等待范围内
- 超时返回后**请求仍在继续处理**——需要再次调用等待；返回码与请求包中的错误字段分别表示"等待本身"与"处理结果"的错误
- 中止语义有区别：单请求时中止当前处理；多请求时**只中止等待（释放等待），不中止处理**

## 二、TOPPERS：先确定家族，再谈语义

第三代 TOPPERS 内核（ITRON 系）是**四个不同家族**，规范分开规定：

| 家族 | 定位 |
|---|---|
| **ASP3** | 基础内核：**无保护、单核** |
| **HRP3** | ASP3 + **保护**（内存保护、时间分区、对象访问保护、扩展服务调用） |
| **FMP3** | ASP3 扩展为**多处理器** |
| **HRMP3** | **保护 + 多处理器**兼具（可视为 HRP3 的多核扩展，或 FMP3 加保护） |

- 就绪队列设计也随之不同：HRP3 **每个保护域一个**就绪队列；FMP3 **每个处理器一个**；**HRMP3 两者结合**（按保护域 + 按处理器），且只在某域实际用到的处理器上建队列以省内存
- 目标硬件要求（HRMP3）：同构多核（大致 2–8 个）、**每个处理器都要有特权/非特权模式与 MMU/MPU**、且所有处理器能执行同一份二进制
- 与 ASP3 一样：**内核内不做动态内存管理**，内核对象静态创建（只为应用提供固定大小的内存池）

**上下文类型（决定服务调用合法性）**：任务上下文、非任务上下文、ISR、循环处理程序、闹钟处理程序各有一套合法性规则。

## 三、共同的分析要求

1. **先确定家族/规格**（ASP3 还是 HRP3/FMP3/HRMP3；T-Kernel 的版本与规格）——保护与多核语义不同
2. **恢复每个调用的上下文类型**（任务 / 准任务 / 任务独立；任务 / 非任务 / ISR / 循环 / 闹钟）
3. **静态配置生成的 task/handler 可以没有普通 xref**——找配置与生成结果，而不是判死代码

## 决策树

```
拿到 T-Kernel / TOPPERS 目标
├─ 先确定规格家族
│    ├─ T-Kernel：确认版本与规格（设备管理、系统状态章节）
│    └─ TOPPERS：ASP3 / HRP3 / FMP3 / HRMP3（保护与多核语义不同）
├─ 某服务调用"非法"或被拒
│    ├─ 恢复它的上下文类型（任务 / 准任务 / 任务独立；ISR / 循环 / 闹钟）
│    └─ 对照规范的有效上下文表，而不是按 API 名推测
├─ 设备驱动相关
│    ├─ 六个处理函数分别以哪种上下文运行（准任务部分）
│    ├─ 必须可重入且不保证互斥
│    └─ 异步请求：发起与等待分离，完成顺序可不同但结果保持顺序一致
├─ 超时后行为
│    └─ 请求仍在处理，需再次等待；等待错误与处理错误是两回事
└─ 找不到 task/handler 的创建点
     └─ 静态配置生成，别判死代码
```

## 工具与验证

- 规格：目标属于哪个家族/版本（保护与多核支持）
- 上下文：每个调用的执行上下文类型与规范规定的合法性
- 设备：`tk_def_dev` 注册的处理函数集合与它们各自的运行上下文
- 配置：静态配置与生成结果（task / handler / 对象）
- 验证：能同时说清「规格家族 + 该调用的上下文类型 + 该对象是静态配置还是动态创建」

## 该平台的坑（汇总）

- **只恢复 API 名不恢复上下文**：合法性完全取决于上下文类型
- **在任务独立部分调用会等待或隐式指定发起任务的服务**：规范禁止
- **把准任务部分当普通任务**：它有独立的处理器模式与栈空间
- **以为设备驱动函数之间自动互斥**：不保证互斥，驱动需自己处理，且必须可重入
- **按请求顺序推断完成顺序**：完成顺序可不同，但结果要保持顺序一致
- **超时后以为请求已中止**：处理仍在继续
- **把等待错误与处理结果错误混同**
- **不区分 TOPPERS 四家族**：保护与多核语义不同，跨家族套用会错
- **在内核里期待动态内存管理**：这一系内核对象静态创建
- **把静态配置生成的 task/handler 当死代码**