tgoskits/Starry OS 改进方案与进展

[ZhiyuanSue]

与AI合作对starry OS改进的开发方案和进展情况

三种改进starryos的开发方案

注：修复bug/功能添加的过程，不是让AI代替你的过程，而是你提升自己的过程。所以，需要你向AI学习，包括OS的设计实现思路、OS的调试思路。到你提升到一定程度，你将以架构师的角度来指导AI完成OS的研发

注：小步快跑很重要！在提交PR前，先下载/merge最新的tgoskits 中dev分支的最新代码，可能dev分支已经有了新的代码，覆盖/冲突/重现你的PR中的部分内容。如出现这种情况，通过大模型分析最新的dev分支的代码，并更新PR，再提交。

注：合理的commit内容撰写参考：例如 rcore-os/tgoskits#219 （来自 @Tempest 赵光烨），给出了bug 描述，根本原因分析，fix描述，测试plan, 修的戴内核代码和测例简要说明。但这个例子提供较早，没有提交到dev分支中。

开发方案的前期环境支持

• 能在本地CI，本地可建立与github上一致的docker开发与测试环境
• 对单点功能修复的测试支持：支持在仓库中添加可发现某个syscall相关或某内核某功能点有bug/实现缺失等情况的C（已实现）和Rust（待实现）源码级用户态测例用例程序（规模），CI可在4个硬件环境+alpine linux中自动测试
• 支持完整linux app的测试支持：支持在仓库中添加脚本，可通过 apk add (alpine linux环境)或apt install (debian linux环境)来安装linux app，CI可在4个硬件环境+alpine/debian linux中自动测试

一、方案一：以1~2个syscall为引导的starryos改进

注：目前在支持基于musl-libc的alpine和基于glibc的debian两个linux distributions。
助教微信id：“Mr Graveyard”

进行方案一的项目实习，是参加方案二和方案三的基础。请联系助教了解细节。

当前系统调用完成情况统计

测例完成情况统计表：https://docs.qq.com/sheet/DRnhPVk13SFdsemdq?tab=BB08J2 各位注意认领后再开始工作
系统调用优先级列表：https://github.com/rcore-os/linux-compatible-testsuit/blob/dev/docs/starryos_syscall_priority.md

1. 让大模型分析syscall的通用性和重要性，并进行排序，形成文档：https://github.com/rcore-os/linux-compatible-testsuit/blob/dev/docs/syscall_priority.md
2. 选择一个syscall，让大模型根据 man 2 syscall-nanme 分析这个syscall的语义，并生成用户态测例，能够分析在linux在正确执行或非正确执行该syscall的返回情况，并通过 assert判断各种返回情况的正确语义。
3. 在本地开发，在starryos中添加并测试这个源码级的用户态测试用例（参考 feat(starry): add C/Rust userspace test case infrastructure tgoskits#235 PR： feat(starry): add C/Rust userspace test case infrastructure ），一般位于 https://github.com/rcore-os/tgoskits/tree/dev/test-suit/starryos/normal/ 目录下，如果某 assert失败，则大概率starryos有bug，就与大模型合作进行修复。
4. 修复完毕并自己review且理解并掌握错误的原因和修改的原因后，提交PR（包含源码级测例和对内核的修改）到tgoskits的dev分支。
5. reviewer 与大模型合作查看PR后， merge PR；如果有问题，在PR中给出改进意见，请提交者改进。

二、方案二：以linux app为引导的starryos改进

注：目前在支持基于musl-libc的alpine和基于glibc的debian两个linux distributions。
alpine的助教微信id：“AsakuraMizu”
debian的助教微信id：“fluove_top”

进行方案二的项目实习，是参加方案三的基础。请联系助教了解细节。

1. 按linux app的基础性、简单/复杂度与个人兴趣等角度（可参考app推荐： StarryOS: Debian Boot tgoskits#228 (comment) ）选择某starryos还不支持的linux app
2. 在本地开发，在starryos中通过添加配置文件的方式添加并测试这linux app（可参考 https://github.com/rcore-os/tgoskits/tree/dev/test-suit/starryos/stress/stress-ng-0 中测试stress-ng的4个配置文件）。
3. 在测试过程中，与大模型合作，让大模型每修复一个bug，最好能生成一个针对这个bug的单一的源码级用户态测试用例文件。如果可能存在较为复杂的触发逻辑，难以生成相关的测例，也需要详述该bug根本原因和触发逻辑。可参考改进方案一，添加到starros的源码测试集（在 https://github.com/rcore-os/tgoskits/tree/dev/test-suit/starryos/normal/ 目录下）中，并提交针对这个bug的PR（包含源码级测例和对内核的修改）到tgoskits的dev分支。
4. 重复步骤3 ，进行一个一系列的bug修改和功能改进/添加，直到linux app能正常运行。提交针对linux app运行测试的PR（包含 linux app测试的配置文件）到tgoskits的dev分支。
5. 子课题挑战：1. 多核并行支持与优化；2. backtrace的支持与优化；3. 基于ebpf的内核可观测性能力增强；4. wayland的图形支持；

三、方案三：以移动机器人为引导的全栈starryos改进

注：目前支持sg2002/rk3588，兼容alpine linux为目标
sg2002机器人的助教微信id：“master-ajax”
rt3588机器人的助教微信id：“zhourui747”

starry for sg2002机器人的当前进展：https://github.com/orgs/Starry-OS/discussions/24

当前还在快速迭代开发中，starry on sg2002/rs3588 机器人已经完成了基本功能。想参与方案三的同学，请先在方案一和方案二上进行前期项目实践，打好starry的相关基础，然后联系助教，逐步过度到方案三。

注：子课题挑战：1. 基于NPU/TPU的AI全栈性能优化

基于“一、以1~2个syscall为引导的starryos改进方案”进行PR提交的参考示例

SZH提供了 rcore-os/tgoskits#235 的PR是一个提交fixbug的PR的参考示例，应该包含两部分：

1. C源码测例和相关文件，位于 https://github.com/rcore-os/tgoskits/tree/dev/test-suit/starryos/normal/helloworld/c 目录下。
2. 对arceos/starry内核组件的修改。由于这只是一个例子，所以这里没有。
   另外，还提供了 https://github.com/rcore-os/tgoskits/blob/dev/test-suit/starryos/GUIDE.md 说明了 添加 StarryOS QEMU 测试用例的详细内容。

基于docker container进行开发的参考示例

这是一个提交PR的例子( rcore-os/tgoskits#252 )，整个过程是基于 https://github.com/rcore-os/tgoskits/pkgs/container/tgoskits-container 中的image，在container中完成。大致执行命令如下：

#用自己的GitHub 的 Personal Access Token (PAT) 登录docker
echo ghp_Ig6WW580bNNu1CuD4Gqc4mVxcM15n41YC0XXXX | docker login ghcr.io -u chyyuu --password-stdin

#下载docker 镜像
docker pull ghcr.io/rcore-os/tgoskits-container:latest

#进入docker container中进行开发 $(pwd)可以是包含本地的tgoskits的目录
docker run -it --name tgoskits
-v "$(pwd)":/workspace
-w /workspace
ghcr.io/rcore-os/tgoskits-container:latest /bin/bash

#在 docker中进一步安装相关工具 claude code... ，能够进行AI编程，git使用的等，比如:
apt install vim openssh-server openssh-client ...
curl -fsSL https://claude.ai/install.sh | bash //安装claude clode CLI
....

# 进行开发，添加 test_pipe2 测试用例，测试通过
cargo starry test qemu -t riscv64 -c test_pipe2
cargo starry test qemu -t aarch64 -c test_pipe2
cargo starry test qemu -t x86_64 -c test_pipe2
cargo starry test qemu -t loongarch64 -c test_pipe2

# 提交代码
git push chy dev:dev

在自己的repo中，提交PR

方案一：参与人员初步安排

• 生成新的Linux兼容的测例
  相关新增测例存放在本仓库的dev分支的test文件夹中
  目前进展：已经跑通流程，需要继续按照docs里面的优先级文档增加新的测试

• 使用生成的Linux兼容测例，测试starry OS并修复bug，提交pr
  使用dev分支的run_all_tests脚本进行运行测例，使用ai查看运行结果并修复并提交pr
  目前进展：已经跑通流程，可以用AI较为自动的测试，修复，提交pr（可能需要少量人工介入）
  目前相关人员：朱懿、王乙凡、戴骏翔、徐子航、郭士尧、李璜华、王铮

• merge相关pr
  建议探索方向：使用ai来review相关pr。使用cli工具配合AI快速总结pr的修复内容，审查pr的编码规范等问题。
  目前进展：尚未得到流程跑通的反馈，但已经可以看到ai reviewer的参与
  目前相关人员：王铮

• step4: 添加已经通过的测例到tgoskits的ci测例集合中，不断迭代完善tgoskit的ci测试范围
  目前进展：已经跑通流程
  目前相关人员：邵志航、周睿、赵长收

当日进展

为让大家相互了解，避免重复，冲突等，请：
如当天有进展，请当天及时在下面写出（下面是例子）：
2026.04.16
xxx：今天建立了..., 修复了....

周一（2026.4.20）计划

• 对于syscall_priority.md文件中指定的一百多个syscall是否在https://github.com/rcore-os/tgoskits/tree/dev/test-suit/starryos/normal 中已经存在测例及是否通过情况进行搜集并统计。
  相关人员：戴骏翔
  预计完成时间：周一上午
• 根据上一步的统计情况，持续跟新这个统计表，并走完从写测例、测试测例发现bug，修复bug，提交PR(测例源码+修复代码)这4步构成的整个流程。
  相关人员：戴骏翔、朱懿、王乙凡、徐子航、郭士尧、李璜华、王铮
• 准备好三个架构的debian rootfs支持
  相关人员：赵长收

[AsakuraMizu]

wz

2026.4.16

在 AI 帮助下设计 PR review 工作流

[wyatt-dai]

2026.4.16
尝试使用python sdk自动生成测例，在让agent进行代码纠错时稳定出现错误码1234报错，官网该错误码让联系客服，自行调整未解决，等待客服回复锁定问题原因

2026.4.17
客服回复说明可能是网络波动或者代理原因，可确定不为我的问题原因，再测试了一下修改prompt长度和token数限制，无法与报错构建直接关联，放弃python脚本接入api的方案
按照原来的生成流程生成十余个测试程序，部分已上传，其余存在具体测例需要调整的情况，修改进行中

2026.4.21
形成busybox测试
失败命令列表：https://github.com/wyatt-dai/tgoskits/blob/dev/test-suit/starryos/docs/Failed_Tests.md

[leeehh]

lhh

2026.4.16

跑通starry和linux测试流程，让agent设计流程并按流程工作

2026.4.17

跑通了最新的18个测例，用 agent 根据日志纠错并修复starryOS代码，目前18个测例全部通过（原本只通过2个），提交了PR
rcore-os/tgoskits#237

2026.4.20 - 4.24

https://docs.qq.com/sheet/DRnhPVk13SFdsemdq?tab=BB08J2 领取syscall任务
按照提交测例+代码修复的方式，提交PR，rcore-os/tgoskits#278
提交PR, rcore-os/tgoskits#285
rcore-os/tgoskits#300

[eternalcomet]

添加了新的测试，涵盖文件系统操作，futex和同步，poll相关内容。更新了测例表格。
#12

[BattiestStone4]

工作总结：StarryOS 测试用例基础设施与 helloworld 测试

完成内容

PR #235（已合并至 dev 分支）：

1. 新增 helloworld C 测试用例 — 支持 x86_64、aarch64、riscv64、loongarch64 四个架构，包含 CMake 交叉编译配置、C 源码、prebuild.sh 依赖安装脚本及各架构 QEMU TOML 配置
2. 编写中文贡献者指南 (test-suit/starryos/GUIDE.md) — 涵盖目录结构规范、纯 Shell / C 测试用例添加流程、TOML 字段说明及注意事项

CI 结果

全部通过，包括：

• Starry 四架构测试（x86_64, aarch64, riscv64, loongarch64）
• ArceOS 四架构测试
• Axvisor 相关测试
• 格式检查、Clippy、单元测试

排查并解决的问题

问题	原因	解决方式
staging root missing guest tool ld	rootfs 缺 binutils	prebuild.sh 安装 binutils
'stdio.h' file not found	clang sysroot 缺 C 标准头文件	prebuild.sh 添加 gcc musl-dev
loongarch64 helloworld segfault	二进制动态链接，缺 loader	调整链接方式

提交记录

Commit	说明
9c3d3cb3	添加 helloworld C 测试用例及 GUIDE.md
7bca1a7b	添加 prebuild.sh 安装 binutils
289395c2	添加 musl-dev 解决 stdio.h 缺失
734eaa9f	GUIDE.md 改写为中文

[Ticonderoga2017]

2026.04.21

• pull dev分支代码，在本地验证对findutils的支持情况
• 准备四个架构的rootfs
• 生成配置文件，执行测试指令
• aarch64，riscv64，x86_64，loongarch64在/etc目录下测试功能正常
• 在根目录下执行测试耗时过久（超过60s），且耗费内存过高 （超过128M）

2026.04.22

一、工作内容

1. LoongArch64 QEMU 环境修复

尝试在 loongarch64 上运行 helloworld 测试，发现本地 QEMU 版本过低（8.2.2），启动时报 ram_size 错误。升级到 10.2.1 后解决。

2. Procfs 性能优化（已实现并验证，后还原）

• 消除 N+1 查询：SimpleDirOps trait 新增 child_info() 方法，read_dir() 枚举目录项时跳过完整 lookup
• 轻量化 task 枚举：新增 task_pids() 返回 Vec<u64> 替代 tasks() 的 Vec<AxTaskRef>
• 用户栈缩减：USER_STACK_SIZE 从 8MB 降为 2MB

二、遇到的问题与解决方案

问题 1：find /proc 超时（>60s）

原因：read_dir() 对每个子项执行完整 lookup()，每次都要锁 TASK_TABLE RwLock、clone Arc 引用、分配结构体，构成 N+1 查询模式。
解决：为 SimpleDirOps 新增 child_info() 快速路径，ProcFsHandler 和 ThreadDir 直接返回 inode + node_type，跳过完整 lookup。

问题 2：find /proc 触发 OOM

原因：loongarch64 平台 axconfig.toml 中 phys-memory-size = 0x800_0000（128M），而 high-memory-base = 0x8000_0000（2GB）超出 QEMU 提供的物理 RAM 范围。尝试增大 phys-memory-size 到 256M/512M 后，高内存区域映射到不存在的物理地址，实际可用内存不变。
解决：

• 将 phys-memory-size 设为与 low-memory-size 相等（256M），使用单区域模式
• QEMU 配置改为 -m 256M
• 测试程序使用 -maxdepth 2 限制递归深度，输出重定向到 /dev/null 减少页缓存压力

验证结果

LoongArch64,x86_64, aarch64,riscv64四个架构全部 5 个文件系统测试通过。

提交了pr：rcore-os/tgoskits#310

2026.04.22

grep / sed / awk 综合测试，用管道联合三个命令进行测试,测试覆盖：

• grep 4.x (7 cases) — pipe match/no-match, grep -r /etc, regex, -i, -v
• sed 4.x (6 cases) — pipe s///, s///g, sed -i 替换/删除/多表达式, -n 2p
• awk 5.x (6 cases) — $2 字段, NR 行号, BEGIN/END, 条件过滤, 算术, -F 分隔符
• 联合管道 (5 cases) — grep|sed, grep|awk, sed|awk, grep|sed|awk 三级管道, 端到端 grep -r|sed -i|awk 工作流

发现的 Bug

sed -i（in-place 编辑）在 StarryOS 上产生空文件：

echo "hello" > /tmp/f
sed -i 's/hello/world/' /tmp/f
cat /tmp/f   # 预期: world  实际: (空)

根本原因

GNU sed 实现 -i 的步骤：

1. open(原文件, O_RDONLY) — 读取原始内容
2. mkstemp(同目录临时文件) — 创建临时文件
3. 将修改后内容 write 到临时文件
4. close 临时文件
5. rename(临时文件路径, 原文件路径) — 原子替换
   Bug 出在第 5 步。 StarryOS 的 /tmp 挂载点使用 tmpfs（内存文件系统），tmpfs 的文件数据存储在 DirEntry 的 user_data 中的页面缓存（CachedFileShared）里。
   当 DirNode::rename 执行时，原实现对源和目标都调用了 forget_entry，将缓存的 DirEntry 从目录缓存中移除。下次打开重命名后的文件时，lookup_locked 缓存未命中，MemoryNode::lookup 创建一个全新的 DirEntry，其 user_data 为空。CachedFile::get_or_create 找不到旧的页面缓存，于是创建了一个空白的页面缓存。原始数据随旧 DirEntry 的释放而丢失。

触发条件

• 文件位于 tmpfs 文件系统（/tmp）
• rename(newfile, existingfile) — newpath 必须已存在
• rename(newfile, nonexist) — 同样触发（因为 forget_entry 不区分）

修复逻辑

1. 从源目录缓存中取出（而非丢弃）源 DirEntry
2. 清除目标位置的旧 DirEntry（如存在），递归释放其子节点
3. 将源 DirEntry 以目标名称插入缓存 — 页面缓存得以保留
4. 后续打开目标文件时，缓存命中，CachedFile::get_or_create 找到已有页面缓存，数据完整

已提交pr：rcore-os/tgoskits#339

2026.04.30

为 StarryOS 添加 util-linux 2.38+ 核心工具链支持，使以下用户态工具可在 StarryOS 上正常运行：

工具	功能	状态
mount	ext4 loop 设备挂载/卸载	已验证
fdisk	磁盘分区表列表	已验证
losetup	loop 设备 attach/detach	已验证
blkid	块设备文件系统识别	已验证
pivot_root	根文件系统切换	已验证

内核层扩展开发

Loop 设备扩展

• 创建时将后端文件完整读入内存，后续块 I/O 直接操作 Vec<u8>
• 实现 BlockDriverOps trait（read_block / write_block / flush）
• 通过 LoopDevice::as_dyn_block_device() 返回 Box<dyn BlockDriverOps>

新增 ioctl 命令：

命令	用途	值/来源
LOOP_CONFIGURE	原子配置 loop 设备（fd + 信息）	linux_raw_sys
LOOP_GET_STATUS64	获取 loop 设备 64 位状态	linux_raw_sys
LOOP_SET_STATUS64	设置 loop 设备 64 位状态	linux_raw_sys
HDIO_GETGEO	虚拟 CHS 几何信息（供 fdisk 使用）	0x0301
BLKSSZGET	获取逻辑块大小	linux_raw_sys
BLKIOMIN	最小 I/O 大小	linux_raw_sys
BLKIOOPT	最优 I/O 大小	linux_raw_sys

挂载系统

ext4 挂载流程（mount_ext4 函数）：

1. 解析 source 设备路径（如 /dev/loop0）
2. 将设备 downcast 为 LoopDevice
3. 调用 as_dyn_block_device() 获取 Box<dyn BlockDriverOps>
4. 通过 ax_fs::new_filesystem_from_dyn() 创建 ext4 文件系统实例
5. 在目标路径挂载

pivot_root 实现（sys_pivot_root 函数）：

校验规则：
  - put_old 必须是 new_root 的子路径
  - new_root 不能是 "/"
  - new_root 必须是目录且是挂载点

执行：
  - 调用 FsContext::pivot_root() 交换根挂载点

辅助系统调用

系统调用	用途
mknodat	创建设备节点/命名管道
sync_file_range	同步文件数据到磁盘
rseq	可重启序列（注册）
setregid	设置真实/有效组 ID
getresuid	获取真实/有效/保存的 UID
getresgid	获取真实/有效/保存的 GID
pause (x86_64)	等待信号

preadv2/pwritev2 参数映射修复：

• 跳过 arg4（pos_h），使用 arg5 作为 flags 参数，与内核 ABI 对齐

pr: rcore-os/tgoskits#459