实验小项目招新：分析并设计与操作系统无关的设备驱动及其框架

[chyyuu]

目标：（学术研究类）分析并设计跨操作系统的设备驱动及其接口/框架
设备驱动程序与操作系统内核有一定的关联度，本项目探索设备驱动程序对操作系统的内核依赖性，以及共性依赖，设计处跨操作系统内核的设备驱动的接口/框架和各种驱动

参考：
具体的驱动实例

• https://github.com/rcore-os/virtio-drivers
• https://github.com/rcore-os/nvme_driver
• https://github.com/rcore-os/cadence-macb-driver
• https://github.com/rcore-os/e1000-driver
• https://github.com/rcore-os/isomorphic_drivers
  已有的探索
• Uniform Driver Interface
• Project UDI:Uniform Driver Interface

注：偏学术研究类

如有兴趣一起来探索，请联系我 yuchen AT tsinghua.edu.cn OR 微信 id chyyuu

[ZhiyuanSue]

我最近的阅读相关记录放在https://github.com/ZhiyuanSue/Personal_Readings
其中DailyWork.md以流水账的形式记录每日工作，并且后续会陆续更新，Paper文件夹下包括了阅读的一些论文。
目前阅读和尝试的包括redox和biscuit操作系统，但是redox编了近20G内容，无力探索，biscuit则是用go语言编写的一个os，对这个的看法，则是对于一些语言特性与操作系统的关系，例如垃圾回收方面，在Linux内核中C代码一般使用引用计数的方式来记录，当为0的时候则清理掉，而go则自带垃圾回收器，对于rust则施加了严格的静态检查，以及离开作用域之后的drop等等方式。在之前通过rust for Linux进行驱动移植的时候，这些语言特性其实有不少影响，甚至于，go那篇论文用的是go1.1版本，但是在之后的1.5和1.8又用了更新的GC方法。总之，在考虑与OS无关这件事情上，必须考虑语言本身的影响。
另外，关于如何设计跨操作系统的驱动，我还考虑阅读以下一些内容：uefi标准对于设备的抽象，虽然它并没有启用中断，但是确实用轮询的方式来驱动很多设备。Apple的Darwin内核中I/O Kit部分对于驱动的管理，至少对于Darwin内核的研究，反正资料甚少。另外，在Rust for Linux内核邮件列表，我看到还有对于显示驱动的DRM框架的内容，一个思科的文件系统的设计，我认为这些框架值得一看。
除此之外，我还了解了LFS，如何从一个内核去构建一个系统。
最后，关于最近华山派的事情，在之前的a1000板子上面，rust for Linux提供了一个phy驱动，而204域控制器本身没有phy是直连的，因此，华山派确实需要一个phy驱动，由于phy是一个IEEE802.3有所规定的模块，可以试着在Rust for Linux中实现一个，并移植到arceos中，而且，由于这是一个公版的设计，本身应当可以移植到arceos的主线中（但愿贾博士不要对我的代码质量吹毛求疵）。相比于网卡驱动本身各家有各家的实现，phy驱动的设计我认为更具有统一性。

[ZhiyuanSue]

1、最近在备课的需求下，大概了解了e1000网卡的情况，尤其是rust for linux下e1000网卡实际工作的原理。
结合之前写rust版本网卡驱动的经验，我认为重构一个网卡框架是可行的。
但是抽象的越多，实际则需要填写相关的内容就越多
大致思路如下
-操作系统抽象层，提供os相关的一些函数
-硬件抽象层，这里面全都是具体的写寄存器的操作。
-描述符层，这里面包括对网卡描述符的一些抽象，主要是对具体描述符的各个字段的操作。但是说实在的，不同厂家对描述符的定义未必一致，而且各个字段的设计不同。
-环形缓冲区层，主要是对单个环形缓冲区的管理包括其重填等等操作。
-网卡逻辑层，网卡的主要逻辑放在这里。
详细的设计，感觉还是需要更多的参考一些资料，但是以此作为重构我认为是可行的。
2、那两天听了报告以及陈老板对于比如模块化操作系统的情况，rust的情况。以及考虑到我近日对rust for linux的一些源代码的观察。关于这个课题，我有个想法。
我认为，应当用少量的C去完成OS最核心最需要性能的比如调度部分以及锁和IPC等等部分以实现其高性能，而在外面，仿照rust for linux封装一层rust，从而用rust对其余组件，例如文件系统，网络栈等等进行重构。
首先，作为一个C程序员，我不喜欢rust，尤其不喜欢rust去写os，因为语言和编译器做的太多的事情，给我一种失去对硬件底层细节的掌控的感觉（高级语言各有各的情况，但rust现在这样没个统一标准和奇奇怪怪的生态，我觉得是个问题。）而这在os这个领域，失去硬件掌控就意味着性能问题，陈老师认为两种语言的差异可能在5%左右，单单考虑语言这是有可能的，但是在os领域，编译器对于具体CPU的硬件没有那么了解，真正了解CPU以及cache的内容的是os编写者，这种差异可能会扩大，即使rust本身编译器很优秀。
同时，我不否认，规模大了之后，软件工程导致的C带来的重大的漏洞问题，因此，除了性能要求极高的核心部分之外，我不介意用rust去构建其余部分。而且从安全性的角度来说，这是可行且更优的。
对于这个最核心用C，其余用rust写OS的方案，我承认有模仿R4L的痕迹，但是，与R4L不同，R4L面对全部的这么多Linux内核代码，是无力重构的，从而很多时候沦为玩具而非必选项，而这样一个OS的设计，从开始就规定好两者的界限。我认为是可行的一种较好的平衡性能和安全的方案。关于os的syscall接口，我是打算按照unix认证的标准而不是其他的标准去做的（什么musl之类的，关我啥事。我就做个纯纯unix就完事了呗）。
至于为什么跟这个课题相关，因为打算用这种方式去验证并构建一波rust的驱动相关层面的内容呀。。。不管咋说，先考虑跨语言，都是导师的任务嘛，要毕业嘛，我总不能跟师兄一样嘛~（叹气）