开源操作系统训练营项目二周报汇集

[Azure-stars]

请大家在这里描述自己的选题方向、工作进展和对应的疑问（若有），格式类似如下：

• 选题：starry-next 完善
• 仓库：https://github.com/Azure-stars/Starry-On-ArceOS
• 进展：成功读取 disk.img 并且运行测例，这里有附图
• 疑问：如何去实现 clone syscall，有没有什么思路

[BattiestStone4]

选题：starry-next 完善
仓库：https://github.com/BattiestStone4/Starry-On-ArceOS
进展：成功读取 disk.img 并且运行os初赛测例。
整理出一份初赛测例中未实现的系统调用列表：

syscall_id	syscall_name
17	getcwd
23	dup
24	dup3
34	mkdirat
40	mount
56	openat
59	pipe2
153	times
160	uname
169	gettimeofday
173	getppid
214	brk
220	clone
221	exec

其中已实现17、23、24、169号调用。
17 getcwd

23、24 dup dup3

169 gettimeofday

观察发现，一些系统调用（如openat）是一系列测例都需要用到的，比如close，open，openat等测例。
为此也可以先完成一些测例共同需要的系统调用。

疑问：
1.pipe2中，需要传入一个数组，如何使用tf.arg0()转换为数组地址？
2.riscv中只有openat一个调用，而x86_64中open和openat是两个系统调用。riscv下不能简单的直接套用api中的sys_open，在编写过程中如何保证实现openat，同时不破坏x86_64下使用原有的open？

[chy669086]

选题：POSIX 相关功能接口

仓库：https://github.com/chy669086/posix-api

进展：实现了一部分信号量的接口，还没有在操作系统跑起来，但是可以在用户态跑了，比如 semaphores 里面的 test 模块。

疑问：

1. 很多接口本身并不是一个系统调用，是多个系统调用的集合，我直接写成用户库可以吗
2. 我的解耦合方式是定义了一个 POSIX 接口相关的库，内部实现由外部库给出，外部库直接依赖这个接口库，这种形式是否算是真正的解耦合

[NoahNieh]

选题：Python + OpenCV
仓库：https://github.com/NoahNieh/Starry-New/tree/python
进展：在Starry-New上面跑完了test___all__.py

疑问：

• 用的是python3.11.8-86_64-linux-musl。感觉好像没做什么工作就跑过了，似乎本身就有足够的支持？

[xingmin1]

• 选题：starry-next 完善

• 仓库：暂时还没有

• 进展：成功读取 disk.img 并且运行测例，改了一下getpid系统调用，正在看axns、tls、clone，正在实现clone
  

• 疑问：

  1. 我看ppt是fd_table和aspace等资源要用namespace管理，但目前我还不太清楚axns和tls怎么使用的、怎么实现的？是不是在概念上和linux的差不多，也要去了解一下linux的namespace？
     

  2. clone要实现到什么程度？是不是可以先实现一个基本的，然后在后面按需实现？
     

[Azure-stars]

选题：Python + OpenCV 仓库：https://github.com/NoahNieh/Starry-New/tree/python 进展：在Starry-New上面跑完了test___all__.py

疑问：

• 用的是python3.11.8-86_64-linux-musl。感觉好像没做什么工作就跑过了，似乎本身就有足够的支持？

说明 python 移植到 Starry-New 之前的工作做的比较好，不用我们进一步去调整，是一件好事。
现在就可以尝试运行给出的 OpenCV 测例了，看看能不能运行起来

[Azure-stars]

选题：POSIX 相关功能接口

仓库：https://github.com/chy669086/posix-api

进展：实现了一部分信号量的接口，还没有在操作系统跑起来，但是可以在用户态跑了，比如 semaphores 里面的 test 模块。

疑问：

1. 很多接口本身并不是一个系统调用，是多个系统调用的集合，我直接写成用户库可以吗
2. 我的解耦合方式是定义了一个 POSIX 接口相关的库，内部实现由外部库给出，外部库直接依赖这个接口库，这种形式是否算是真正的解耦合

你这样的话像是做了一个中间的胶水层，其实也很好！不过我们可能更希望的是顺便把实现 syscall 的外部库给他做出来，只需要关心一些比较复杂的 syscall 就好，做出来一两个也是非常好的（太简单的 syscall 就可以不用做了hh）
还是举之前的 syscall_futex 的例子，你可以尝试实现一个单独的 crates，实现各种 futex 功能，然后需要内核实现的功能（比如 yield 当前任务等）都可以通过 trait 等形式来实现。

[Azure-stars]

• 选题：starry-next 完善

• 仓库：暂时还没有

• 进展：成功读取 disk.img 并且运行测例，改了一下getpid系统调用，正在看axns、tls、clone，正在实现clone
  

• 疑问：

  1. 我看ppt是fd_table和aspace等资源要用namespace管理，但目前我还不太清楚axns和tls怎么使用的、怎么实现的？是不是在概念上和linux的差不多，也要去了解一下linux的namespace？
     

  2. clone要实现到什么程度？是不是可以先实现一个基本的，然后在后面按需实现？
     

1. 可以先把自己的工作push到一个fork出来的仓库，这样也方便大家一起来共享成果讨论参考～。
2. axns 的实现逻辑可以参考一下群里发的 PPT，和Linux的namespace其实不完全一致。它只是一个用于进程隔离的地址块而已。我们下次讨论也可以讲一下。
3. 我们的syscall都是为测例服务的，所以你可以先实现基本的，然后测例发现哪些不足就补充哪些就好

[Azure-stars]

选题：starry-next 完善 仓库：https://github.com/BattiestStone4/Starry-On-ArceOS 进展：成功读取 disk.img 并且运行os初赛测例。 整理出一份初赛测例中未实现的系统调用列表：

syscall_id syscall_name
17 getcwd
23 dup
24 dup3
34 mkdirat
40 mount
56 openat
59 pipe2
153 times
160 uname
169 gettimeofday
173 getppid
214 brk
220 clone
221 exec
其中已实现17、23、24、169号调用。 17 getcwd

23、24 dup dup3

169 gettimeofday

观察发现，一些系统调用（如openat）是一系列测例都需要用到的，比如close，open，openat等测例。 为此也可以先完成一些测例共同需要的系统调用。

疑问： 1.pipe2中，需要传入一个数组，如何使用tf.arg0()转换为数组地址？ 2.riscv中只有openat一个调用，而x86_64中open和openat是两个系统调用。riscv下不能简单的直接套用api中的sys_open，在编写过程中如何保证实现openat，同时不破坏x86_64下使用原有的open？

1. pipe2 的实现可以参考这个：https://github.com/Starry-OS/Starry-New/blob/main/api/linux_syscall_api/src/syscall_fs/imp/io.rs#L223，其实也可以读文档了解一下 pipe2 传入的 arg0 的意义，如下。

The array pipefd is used to return two file descriptors referring to the ends of the pipe. pipefd[0] refers to the read end of the pipe. pipefd[1] refers to the write end of the pipe.

所以它本质就是一个数组地址，直接取前两个元素就好（假设地址有效）

2. 我们的目标是将来将所有的 syscall 实现都接入到 posix_api 层，但是目前难度还是有点大，现在可以先实现在 starry-next 层。另外 openat 应该在 x86_64 和 riscv64 下是一致的，而对于 open 调用其实只是 openat 的一个特例（dirfd = AT_FDCWD）。所以可以先共同实现 openat，而对于x86_64下特殊实现 open（参考 https://github.com/Starry-OS/Starry-New/blob/main/api/linux_syscall_api/src/syscall_fs/imp/io.rs#L437）

[Amaranterre]

选题：内核模块独立：动态链接相关

仓库：https://github.com/caozhanhao/yaep

进展：新建了项目仓库，成功在本机运行了starry-new并通过了相关测例；详细研读了RiscV ABI手册的第八章以及gabi的内容，同时阅读了CSAPP中关于程序链接的内容，为后续的开发做好了充足的准备。

[nusakom]

选题：Python + OpenCV
仓库：https://github.com/nusakom/Starry
进展：在Starry-old上面跑完了test___all__.py

[Azure-stars]

选题：Python + OpenCV 仓库：https://github.com/nusakom/Starry 进展：在Starry-old上面跑完了test___all__.py

下一步可以再 Starry-New 上运行这些测例，看看有没有哪些地方需要调整。另外有同学已经实现了这一步，可以进行参考：https://github.com/NoahNieh/Starry-New/tree/python

[yiming-gu]

选题：starry-next 完善
仓库：https://github.com/yiming-gu/Starry-On-ArceOS
进展：加载测试用例镜像，并运行，开始完善系统调用

[nusakom]

选题：Python + OpenCV 仓库：https://github.com/nusakom/Starry 进展：在Starry-old上面跑完了test___all__.py

Starry-New仓库：https://github.com/[nusakom/Starry-New](https://github.com/nusakom/Starry-New)

在Starry-New 上全部运行test___all__.py

[wang-jiahua]

选题：Python + OpenCV
仓库：wang-jiahua/Starry-New
进展：在 Starry 和 Starry-New 上通过了 Python 测例

[hxingjie]

选题：starry-next 完善
仓库：https://github.com/hxingjie/Starry-On-ArceOS
进展：实现读取 disk.img 并且运行测例，已通过测例: gettimeofday, getcwd, dup, dup2, chdir, open, close。具体记录更新在仓库的record中
疑问：chdir这个测例中未实现根据fd获取路径信息，当前实现只是在当前路径下创建文件夹；clone当前的实现只是简单的复制当前进程的信息创建新进程，未实现进程父子关系以及wait系统调用。

[yjymosheng]

选题：starry-next 完善

仓库链接: https://github.com/yjymosheng/Starry-On-ArceOS/tree/main

目前进展:

已经完成的syscall

没有完成的syscall