项目进展

2022-07-21

课程分数公布，项目结束。

2022-07-09

完成结题报告，并发送给邢凯老师。

邢凯老师表示：

收到

同时上传到 GitHub

👍

2022-07-03

进行结题答辩。

答辩结束后，小组成员商定结题报告由陈建绿和张子辰撰写。

2022-07-02

吴骏东、郭耸霄完成数独例程的功能修改与运行。

张子辰对现有代码进行整理。

张子辰、郭耸霄、蓝俊玮制作了答辩的 PPT。

陈建绿继续对 menuconfigure 进行优化。

2022-07-01

张子辰完成了抢占式调度模块。

郭耸霄、蓝俊玮完成键盘输入的处理。

陈建绿完成了 menuconfigure 编译配置方式。

2022-06-29

陈建绿完成对测试模块的编写，开始研究编译配置方式。

2022-06-28

张子辰完成随机数生成模块。

郭耸霄完成向GPU输出的处理。

蓝俊玮尝试完成对鼠标设备输入的处理。

2022-06-26

tailq 模块的一个错误被由陈建绿找出并被由张子辰修复。

2022-06-25

开始常态化小组讨论，主要在中校区 5 号楼 13 楼自习室与图书馆研讨室进行。

lab4 在郭耸霄、陈建绿、蓝俊玮、张子辰的合作下基本完成。

2022-06-24

小组成员基本上完成了期末考试，开始计划在最后一周的任务安排。

2022-06-14

张子辰基本完成了非抢占式调度器，但是仍有 bug 需要修复。

2022-06-13

郭耸霄在本机完成了 ceph 的编译安装。

2022-06-12

郭耸霄、蓝俊玮、张子辰尝试编译安装 ceph，因所需计算机的代价过大而暂时搁置。

2022-06-11

上周的讨论因准备数理逻辑基础考试取消。

第 D 次小组讨论。目前临近考试周，大家无法花费大量时间推进项目，更严重的是，离项目验收的时间已经不到一个月了，Runikraft 仍然没有达到能展示的地步。

我们首先微调了大作业的分工：

蓝俊玮参考Mimalloc: Free List Sharding in Action 和 microsoft/mimalloc 实现 mimalloc 分配器。Mimalloc Rust 只不过是microsoft/mimalloc 的 wrapper，不具有参考价值。

张子辰、陈建绿、吴骏东、郭耸霄继续之前的工作。

然后，我们确定了 Lab4 的分工：选择 ceph。

测试指标：读延迟、随机读速率、顺序读速率、写延迟、随机写速率、顺序写速率、空间效率（实际占用空间/存储的文件的大小）。

郭耸霄在 Vlab 上初步完成了部署。

蓝俊玮和郭耸霄分别独立完成 lab4，其他人继续推进大作业进度。

2022-05-28

第 C 次小组讨论。主要工作是集体开发项目。我们发现，rcore-tutorial-book 的教程并不详尽，照着它实现 virtio 驱动仍然有难度。

2022-05-21

我们进行了第 B 次小组讨论，分析当前进展，重新确定目标并分工。

新的分工：

吴骏东	张子辰	蓝俊玮	郭耸霄	陈建绿
rkargparse	rksched	rkmbox	ns16550	错误代码
数独游戏（展示程序）			virtio-blk	测试
			virtio-gpu	配置

小组成员一致决定，不再以 Unikraft 的源代码为主要参考。按照 rcore-tutorial-book 的第九章写设备驱动。

2022-05-14

我们进行了第 A 次小组讨论，边讨论边开发项目。

这是第 12 周的结束，但是开发进度与预期尚有一些差距。

2022-05-07

邢凯老师表示：

大家各自记得开组会，和我说一下时间，和大家快速捋一遍时间节点和进度。

我们进行了第 9 次小组讨论，边讨论边开发项目。

2022-05-03

我们向邢凯老师汇报项目进度以及遇到的困难：

• 张子辰：目前我遇到的主要困难是 RISC-V 的设计者并没有让操作系统运行在最高权限下，于是我写代码时感到自己的程序的权限不够大。这就导致还需要用 SBI call，于是无法完全消除 ecall 带来的开销。
• 郭耸霄：rkblkdev 的接口已经设计好了，实现正在稳步推进。目前的一个阻碍是这一模块专用的队列。
• 陈建绿：rksched 的接口也已经设计好了，具体实现还在进行。我目前遇到的困难主要是调度器跟底层相关的操作的实现方法。
• 蓝俊玮：rkring 基本上实现好了。还有一些与汇编有关的暂时还没有解决。目前困难是 rksignal 中的内容不知道有什么方式实现。
• 吴骏东：rkparam 核心功能已经写完了，现在正在做和命令行输入的适配。目前的困难是原先对应的 ukparam 实现逻辑较为复杂，需要重新调整。

邢凯老师表示：

👍👍👍。

需要我参与，或者有需要支持的地方，随时联系我就好。

2022-04-30

2022-04-29 日邢凯老师表示

五一期间正是大步快跑的好时候，大家有空的话就撸开袖子放手干，一起加油💪。

所以我们进行了第 8 次小组讨论，主要内容是在一起开发项目。

2022-04-25

进行中期汇报，邢凯老师表示：

很好很好，刚刚讲得非常详细。

2022-04-23

邢凯老师仔细审阅了中期汇报的演示文稿，提出一些建议：

其他部分没什么大的问题，加入risc-v的支持，这是很好的特性，也意味着未来发展上限很高。这块建议在后续部分中的阐述，是不是考虑先在部分核心模块中实现对risc-v的支持，然后再有余力的情况下争取做到全面支持，留有弹性空间？

是打算核心模块都支持risc-v么？

可以把unsafe在ppt里的how讲一下，一是可行性上的权衡，二是讲基于rust实现时，在核心模块会碰到ownership、共享变量以及锁之类的问题，提前打招呼跟大家说明考虑unsafe这种退一步的方式，不要给出过高的预期。

基础好的同学，可以考虑在自己的分工模块中加入risc-v的支持。这块不太合适让所有同学都做risc-v，组长要考虑好每个人的前期积累基础。如果你们五个人都是大牛，那就按这个去做，我会很支持。如果不是所有人都是大牛，那就还是刚才的建议。

主要的考虑是各自的前期积累，rust和risc-v对于大家是有一定挑战的，有积累的同学比较容易快速上手，否则需要一定的时间和精力投入。对于非大牛同学来说，与其分散精力到两个方向，不如聚焦于一个方向。这是分工方面的建议。

这些建议供大家参考哈。

为每个人找到最适合他自己的分工，这块也是一个比较大的挑战。

第 7 次小组讨论：

• 讨论目标：试讲中期汇报及现场讨论改写方法。
• 讨论过程：
  • 张子辰试讲了中期汇报；
  • 其他组员提出对汇报的修改意见；
  • 对具体C代码改写成Rust的方法进行讨论。
• 讨论结果：
  • 中期汇报的演示文稿进行了略微修改，使其可以在20分钟内完成；
  • 对部分改写方式进行了统一。

2022-04-22

​ 中期汇报的演示文稿完成，并交给邢凯老师审阅，邢凯老师表示：

👍👍👍。

并找出一处拼写错误。

2022-04-21

小组讨论分配开发任务。

可行性报告的版本 2 完成，提交给邢凯老师审阅。邢凯老师表示：

👍。

邢凯老师询问中期汇报演示文稿的情况：

记得提前发我ppt，先过一下看看有什么需要修改的。

我们表示预计明天可以完成，邢凯老师表示：

👍好的。

2022-04-20

可行性报告的版本 1 完成，等待小组讨论。

第 6 次小组讨论。

• 讨论目标：确定开发分工及预期进度。

• 讨论过程：

  • 根据概要设计分配任务；

• 讨论结果：

  • 任务分配如下：

  • 	吴骏东	张子辰	蓝俊玮	郭耸霄	陈建绿
    10		rkalloc
    11	rkplat		rkring		rksched非抢占
    12	rktime			rkblkdev	rkclock
    13	rkswrand	rknetdev	rkmbox
    14	rkplat	rkparam	rksignal	9pfs	rksched抢占
    15
    16	不依赖SBI	Rust std	LibC	vfscore	pthread

2022-04-18

可行性报告的版本 0 完成，经过小组讨论，决定大改。此工作改由张子辰负责。

2022-04-17

中期汇报主要由陈建绿和吴骏东负责。

中期汇报将于近期，最早本周三进行。

可行性报告的截止日期为本周六，我们需要加紧进度了。

2022-04-13

第 5 次小组讨论。

• 讨论目标：交流可行性报告撰写情况，筹划开始项目编写。
• 讨论过程：
  • 解决部分小组成员无法编译本小组报告的问题；
  • 对可行性报告的分工调整进行讨论。
• 讨论结果：
  • 将计算机根目录命名为汉字会导致许多麻烦；
  • 可行性报告的撰写工作改为由郭耸霄负责。

2022-04-10

通过掷伪随机骰子的方式确定了可行性报告主要由蓝俊玮负责。

提交按照邢博士的意见重写的调研报告。老师表示：

👍没问题，继续推进可行性报告。

2022-04-06

第 4 次小组讨论：

• 讨论目标：结束可行性报告的撰写，开始分工阅读Unikraft源代码
• 讨论过程：
  • 向邢凯老师发送审阅调研报告的请求；
  • 交流Rust学习进度以及后续部分的学习侧重；
  • 张子辰讲解了概要设计，并现场运行了一个自己用Rust写的小操作系统。
• 讨论结果：
  • 分工待确定；
  • Rust的学习侧重为Rust的高级特性一章；
  • 等待调研报告的审阅结果。

向邢凯老师提交调研报告审阅申请，邢凯老师表示：

收到，项目背景里的内容更多应该放在可行性报告。调研报告是介绍项目本身，所以背景部分应该按项目特性所对应要解决的问题来展开，不应按已知的技术点来介绍.。

项目背景的每一小节部分需要提出该领域面临的问题，并给出这个领域有哪些设计思路，然后给出领域中的各种轮子。立足于回答多个what；立项依据应给出思路，以及需求分析，并说明该思路切合需求，立足于回答why；前瞻性和重要性分析立足于从趋势和现实回答本项目的价值、影响和意义；相关工作是对学术界和工业界的经典工作与前沿进展分类梳理，进一步提供各种轮子的信息。

项目背景按项目的特性及其所面临的挑战/问题进行展开

需要大修哈！

你们确定是要RISC-V 架构了么？如果你们都确认的话，注意控制风险。生态不够成熟，很容易出现中间过程中出现bug没法调试/解决。

整体来说所调研的内容比较详尽了，就是说明性的内容占比过多。各大章节的逻辑和内容安排上需要进一步修改。

接下去会安排对调研报告进行大幅度的修改。

2022-03-30

第 3 次小组讨论：

• 讨论目标：结束调研报告的撰写，开始可行性报告的撰写。
• 讨论过程：
  • 确定许可证；
  • 审阅调研报告；
  • 交流Rust学习进度；
  • 讨论可行性报告分工。
• 讨论结果
  • 程序使用 BSD 3-Clause 许可证，报告使用 CC-BY-4.0 许可证；
  • 确认调研报告不需要继续修改；
  • 可行性报告分工：
    • 理论依据：郭耸霄
    • 技术依据 （主要使用的工具：rustc、cargo、qemu）
      • Rust能写操作系统：陈建绿
      • RISC-V的特权指令，KVM能支持RISC-V架构：吴骏东
    • 创新点+概要设计：张子辰、蓝俊玮
  • 可行性报告初稿的完成时间是2022-04-05。

2022-03-27

调研报告的预发行版本以 $\mathrm{\LaTeX}$ 格式完成，开始交叉审阅工作。

2022-03-26

调研报告的初步版本以 Markdown 格式完成。

2022-03-24

提出要重视内核的安全性，以及打算使用RISC-V架构（但是没有找到RISC-V开发板的购买途径）。邢凯老师表示：

不建议搞的过于复杂。前景是蛮有意思的，可以作为一个长期的工作目标，但以学期长度来限定，务必需要做好风险评估。如果要从指令集层面自底向上来做一遍虚拟化，我是非常支持的。但第一次做的话，建议从成熟生态开始目前来看，arm的发展趋势越来越清晰，其上的虚拟化需求也会越来越明显，目前arm上的虚拟化刚刚开始没几年，可以考虑基于arm来做。

并提出两个问题：

1. 在risc-v上实现unikernel的目的是？
2. 选择两个都不够成熟的生态组合在一起来做的风险是怎么考虑的？

2022-03-19

第 2 次小组讨论：

• 讨论目标：确定时间安排。
• 讨论过程：
  • 最终确定方向；
  • 更改小组名称；
  • 讨论时间安排；
  • 讨论调研报告分工。
• 讨论结果：
  • 方向确定为Rust实现Unikernel；
  • 小组名称确定为runikraft；
  • 争取2022-04-05 前学习完Rust语言、及完成可行性报告；
  • 争取2022-03-25 前完成调研报告；
  • 筛选出rumprun、rusty-hermit、mirageOS、includeOS、clickOS 5个未过时的项目；
  • 郭耸霄负责调研rust优越，兼容性的重要性；
  • 张子辰负责调研Unikraft；
  • 蓝俊玮负责调研clickOS、includeOS、miageOS；
  • 陈建绿负责调研rusty-hermit、rumprun；
  • 吴骏东负责调研往年有关Unikernel的项目；
  • 将每周三第五节确定为讨论时间。

确定最终方向为用rust实现一个unikernel，邢凯老师表示：

蛮好的，进一步丰富和加强它的价值和前景。

确定正式组名为runikraft组，并将仓库部署到OSH-2022课程的Github组织中。

2022-03-14

我们将各自制定的初步设想发给邢凯老师，邢凯老师表示：

这几个项目方向调研的都挺好，难以取舍哈。一个高星⭐项目的基础是相关领域生态好，跟随者足够多，符合未来需求和趋势。从这个角度看，树莓派的生态足够好；嵌入式里主要os是ucos和freertos，生态和支持者也占主流；跨平台的高性能虚拟化实现以及安全性也是未来大势所趋。眼动追踪之前有一组做过，实时性会有较大挑战，在linux下用cpu来做很难保证实时性。确定好一个承载主体/生态，融合各自方向的一部分，给出一个针对未来需求的理想目标，然后给出架构设计，大骨架细化过程中再把各自想要的轮子一个个拿过来拼装起来。

2022-03-12

第 1 次小组讨论：

• 讨论目标：听取老师建议并确定选题。
• 讨论过程：
  • 询问老师参会方式；
  • 得知老师采取腾讯会议参会后，登入腾讯会议并等待；
  • 在老师长时间未进入讨论后，关闭腾讯会议，将讨论模式改为分享调研成果；
  • 蓝俊玮分享了安全容器调研；
  • 吴骏东分享了人机接口调研；
  • 张子辰分享了Unikernel调研；
  • 郭耸霄分享了树莓派上实现操作系统调研；
  • 陈建绿分享了物联网操作系统调研；
  • 张子辰分享了智能电梯系统构想。
• 讨论结果：
  • 否定了上次讨论中确定的首选方向和备选方向；
  • 为进一步的实验准备，应该开始学习Rust语言；
  • 主要研究方向集中于Rust、树莓派、人机交互3个关键词；
  • 进一步调研，为下一次与老师的讨论汇报做好准备。

2022-03-11

拟进行一次小组讨论，确定讨论前的准备工作：分头调研备选方向并在与邢凯老师讨论时进行汇报。

2022-03-10

通过与邢凯老师的进一步沟通，得知分布式文件系统可做的大方向几乎没有了。

disgrafs的高性能优化这块是一个。主要考虑是存取效率，访问效率，索引效率，交互效率，易用性和可用性。例如disgrafs在易用性上采用浏览器作为用户端，交互基于浏览器，这会比较适合分布式文件系统从原来的工业级应用向民用级迁移的趋势，也符合从局域网向互联网迁移的趋势。

第二个初步构想被否决，放弃分布式文件系统方向。

2022-03-09

基本完成文件系统（尤其是分布式文件系统）方向的初步调研。

与邢凯老师讨论后，提出第二个关于分布式文件系统的初步构想。邢凯老师提示可以采用纠删码实现：

纠删码应该满足你想要的特性，比如一个加密后的文件拆分成15块，拿到任意10块就可以还原出加密文件，配合公钥/私钥即可还原。这样文件分片存储在不同位置，其他用户是看不到文件内容的，存取时会自然的形成多路并行传输，效率也有保证。所有权、使用权、存储安全都分离开了。可用性和可靠性可以按用户和文件定制，这块通过纠删码非常容易实现。即使是在互联网的节点时不时出现离线的情况下也能达到99.99%，5个9甚至是6个9的可用性。

经过进一步的调研，我们发现2021年的DisGraFS组已经做的比较完善了，便向邢凯老师询问突破点，邢凯老师表示：

嗯，这个应该算是原型，浏览器端、索引服务器端和存储端都有不少优化空间。还有网络化这块，按理应该是基于加密通信，跑在虚拟专网中。虚拟专网及相应接口倒是可以提供现成的。索引服务这块应该是基于name based和label based，可以认为目前这个是个单用户版，多用户共享版还没有。浏览器端只是适配了一个浏览器，wasm的能力没有完全发挥出来，交互也比较初级。人机交互和图结构化展示在设计中也应该是3D交互式，这是图结构比较好的交互方式，目前用neo4j只是做了平面图，其实在2D屏幕中也可以做到3D交互，类似于unity这种立体呈现的方式。存储端是用java做的，可以适配于大多数系统，对网络接入这块天然要求高一些，跨网以及上下线时的服务连续性也没做。用户自定义的可用性这块也没有实现。

2022-03-08

完成往年项目调研。

提出第一个关于去中心化分布式文件系统的初步构想，但立即被邢凯老师否决。邢凯老师表示：

是说把索引服务器拆成去中心化的么？这个确实还没有。其他部分是去中心化的或分布式的。这块的主要考虑是性能，索引性能对于用户来说是一个关键指标，所以是以集中式或反向代理后的分布式来实现会比较有性能保证。其他几个部分已经是或接近是去中心化的。

多备份的方式已经落伍了。去中心化和区块链没有直接关系。索引效率也就是用户存取数据的效率难以保证。2013/2014年左右Google和facebook用纠删码存储的方式替代了多备份方式，存储空间少用了接近一半。历届涉及到分布式存储的项目中，已普遍采用并实现了纠删码存储，有js、rust、wasm等的实现。

2022-03-05

第 0 次小组讨论：

• 讨论目标：确定初步感兴趣的大作业题目。

• 讨论过程：
  • 确定组名为LJW组；
  • 建立 Github 项目x-LJW；
  • 浏览往届大作业项目；
  • 通过排除法确定方向。
• 讨论结果：
  • 首选方向：分布式文件系统；
  • 备选方向：图形化界面的 Unikernel。

2022-02-28

完成组队。

临时组名为LJW组。