a late proposal.md

docs/catfish-proposal.md

@@ -0,0 +1,72 @@
+# Rust OS多核移植与基于PARD框架的线程级Label管理 方案设计文档
+
+2015011251 王纪霆
+
+## 实验目标
+
++ 完成RustOS在riscv32上的多核开启
++ 使RustOS可在中科院计算所PARD RISCV硬件环境下运行
++ 使RustOS能够在PARD上开启smp
++ 添加控制功能，使得RustOS可以控制/查看PARD的寄存器
+
+如果以上这些要全部实现，可以预料地将无法在八周内完成。
+
+## 实验背景
+
+[LvNA/PARD](https://github.com/LvNA-system/labeled-RISC-V)是一个用于进行内存隔离的硬件系统。它基于[rocket-chip](https://github.com/freechipsproject/rocket-chip)实现，在通常的多核以外，在核与各存储设备间增加了寄存器和额外的模块，并且对总线访问添加了标签，两者相结合下，可以完成对总线访问的控制，即对各核能够使用的缓存大小、磁盘流量进行限制等。
+
+但目前为止，这项工作还有一些问题。首先是作为控制流量的关键——control plane，并未暴露给各核，而需要通过硬件的JTAG机制与板子上的控制模块prm（内含一个linux系统）沟通，并且在prm上实现控制脚本。而prm又和各核无法直接沟通，这样，运行在各核上的OS不仅无法修改寄存器，也无法知晓自己所分配到的资源大小，与PARD系统完全隔离。
+
+如此一来，这个系统仅能进行核间的隔离，而无法完成进程间的隔离。这是因为，为了区分进程、给两个进程打上不同的标签，就必须让OS可以主动修改和设置control plane。
+
+解决这个问题，实现进程级的label管理就是这个项目的主要目的。
+
+## 实验设计
+
+实际上，本项目的两个方向，即多核移植和PARD移植，是可以独立完成的。因为也可以退而求其次，考虑在PARD上只运行单核的线程级标签管理。但最终的目的还是让RustOS接手PARD的所有核，作为一个多核OS运行，对整个系统的运行进行管理。
+
+最理想的方法是让硬件把control plane映射到内存，作为各核的一个设备。但硬件非常复杂，并且中科院方也没有实现这一功能。所以还是对硬件不做修改，依旧通过prm管理control plane，而将prm用串口等和各核连接，让其作为核的一个设备，在核的控制下修改底层配置。
+
+为此，需要做的具体来说是：
+
++ 让RustOS可以在核上运行；
++ 在prm上写脚本（运行在完善的Linux环境，且有现成范例），控制control plane；
++ 在RustOS上写驱动，使其可以与prm交互完成控制；
++ 在RustOS中添加系统调用等，使得操作系统可以管理驱动；
+
+另一边，多核移植所要做的是：
+
++ 开启多核，实现原子操作等，为内核中可能的竞争加锁（Rust已经帮我们做了很多）；
++ 核间进程调度，load balance；
+
+多核这边打算做的简单一些，基本照搬uCore+ on rv64来做，因为主要的设计和优化工作应该交给wrj同学。
+
+## 目前进度
+
+PARD端：
+
++ 完成了实现机理的调研
++ 正在服务器上编译复现（工程太大，本地vivado编译不了）
+
+多核端：
+
++ 完成了ucore+ smp的初步学习
++ 学习了bbl，完成了RustOS on rv32的多核开启
+
+## 暂时计划
+
+如果必须前八周结束，估计是无法做完的。
+
+根据能否在前八周过后继续做，有以下远近期的计划：
+
+### 短期
+
++ 完成rv32 on smp的移植（第5-6周）
++ 完成多核Rust OS在PARD上的运行（第7-8周）
+
+### 长期
+
++ 完成RustOS与PARD的交互协议构建（第9-11周）
++ 实现基于RustOS的进程级标签管理（第12周后）
+
+以上均基于只有本人一人工作的前提，若有其他人协助/加入则根据实际情况而定。