实验小项目招新：Linux Device Driver in Rust

[chyyuu]

目标：
基于Rust in Linux，用Rust写Linux驱动，并且通过层次化模块设计，尽量能做到主要代码能形成crate，能被其他OS重用。

参考：

• https://rust-for-linux.com/
• https://rust-for-linux.com/Android-Binder-Driver.html
• https://rust-for-linux.com/NVMe-driver.html
• https://github.com/Rust-for-Linux/linux/tree/rust-next
• https://github.com/rcore-os/e1000-driver
• https://github.com/rcore-os/nvme_driver
• https://github.com/rcore-os/virtio-drivers
• https://github.com/myrfy001/r4l-e1000

该crate可做到与具体操作系统无关

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

[thy1037]

r4l 学习笔记：
https://thy1037.github.io/r4l-doc/

[shilei-massclouds]

问题：
Rust部分函数在内存不足时，触发panic，例如alloc::vec::push。这个和kernel的设定不符。
为避免此类问题，R4L不支持这种push。
我们需要找出类似的情况，然后统一考虑处理方法。
想法：
在rust/library源码中(包括core/alloc/std等等)，搜索所有可能触发Panic的方法：

实际只有318个。采用搜索关键字"# Panics"，这个应该是合适的，因为它们在用于生成API的comments中，这个必定是规范写法。
然后可以逐个分析即可。
从图中直接可以看到，其中相当数量的是越界问题，我认为这类本质是编码错误，就应该panic；至于内存不足的如vec.push类的，就记录下来；其它的需要看看是否还有与内存不足这种类似的。估计查看一个api大约3 ~ 4秒，工作量是可控的。
其它想法：
我们基于ArceOS写驱动时，是否也面临类似问题。比如，ArceOS在内存不足时，是否也想采取与Linux kernel兼容的方式，不panic而是返回错误。
我没有实践过驱动方面，提一点不成熟的想法。大致两个办法：

1. 事后检查：写驱动后用lint工具检查(clippy之类)且放git ci，如果发现调用不符合kernel约定，就报错。例如alloc::vec::push，报错，提示使用替代方法vec::push_within_capacity(这个在内存不足时不触发panic，而是Result)
2. 事前约束：写驱动时必须调用咱们自己封装的crate，例如起名arceos_driver，盖住alloc::vec之类的，如arceos_driver::vec::push这类可以内部调用alloc::vec::push_within_capacity，其它的直接reexport。这样比较符合程序员的编程习惯，但是封装的工作量比较大。

[ZR233]

现状

由于R4L处于初级阶段，接口变化较快，功能支持不完善，原版内核只有module注册，缺少device、pci注册、net api 等。比如第一版 e1000驱动，在实现过程中，需要在内核中添加大量功能性的rust代码和c_bindgen_helper代码，当Linux版本更新后，必然会产生冲突，导致代码很难合并，适配不同版本内核工作量极大。

新方案

所有改动放入单独的外部module项目，分为设备驱动层和系统兼容层，其中linux的兼容层由于rust驱动 api未稳定，所以直接使用成熟的C代码编写，大部分可以直接复制原有C代码，设备驱动通过FFI调用，与系统兼容层连通，这样只需修改linux兼容层即可适配各个版本。
已实现案例：e1000-rust: E1000E 驱动Rust实现

开发流程

1. 内核中拷贝现有C驱动为外部模块，删除硬件相关代码，只保留系统接口相关代码，形成linux兼容层。
2. 编写操作系统无关的硬件驱动，暴露外部操作硬件的接口，通过cbindgen生成FFI的C接口代码。
3. 在兼容层调用硬件接口。