reverse-skills-max: initial public release (restored, redacted, hardened)
This commit is contained in:
baradok609hecl1pq6qi
@@ -0,0 +1,105 @@
|
||||
# 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 当死代码**
|
||||
Reference in New Issue
Block a user