对于一个模块来说，我们希望它拥有：
- 规范的文档
- 良好的代码风格
- 尽量完备的测试
- 清晰易懂的引导说明
对上述内容，我们的要求如下：
我们引入的模块绝大部分由 Rust 编写，此时通过rustdoc进行文档的检查和生成。
文档的规范详见：如何写文档 - rustdoc 手册 中文版
文档检查和生成指令详见：doc.yml
注意：为了检查是否存在缺失文档与链接，我们引入了
RUSTDOCFLAGS: -D rustdoc::broken_intra_doc_links -D missing-docs关于 README.md 的撰写可见 README.md
关于代码风格的检查器有较多类型，对于 Rust 模块来说，我们默认使用rustfmt和clippy进行规范性和代码风格测试。测试指令详见：ci.yml。
完备的测试指的是尽可能提高测试的覆盖率，涉及更多代码、更多边界情况。我们讨论如下情况的测试：
- 用户态测试：即单元测试，覆盖基本的测试情况
- 内核态测试：对于一些需要运行在内核态下的 crate，如 virtio、page_table 等，需要额外编写相关的内核态测例，并且起一个简单的 qemu 进行测试，可以参见：virtio-driver
- 内核集成测试：内核集成测试仅当内核本体更新的时候会在自身仓库触发测试，从而保证集成测试不会冗余，因此不在模块仓库的 CI 中涉及
因此为了保证基本的测试覆盖，我们需要对于每一个模块编写各自的单元测试或集成测试，测试最基本的内容。
- 测试规范详见：测试 - 通过例子学 Rust 中文版
- 测试指令详见：ci.yml
由于 kern-crates、os-checker 等平台会集中收集各个 crate 并且组织成为一张列表，因此我们需要对仓库进行简单的说明。
简要的说明包括对仓库的说明(about)、文档链接等信息，以及清晰的 README。
以下为做的较为完善的模块的 demo，供参考：
- kspin：包含了完整的文档、单元测试、CI 流程，但是暂未携带内核态测试
- elf_parser_rs：简单的 ELF 分析工具，不需要加入内核态测试
- virtio-driver：携带内核态测试
以下为 crates 仓库建设时可能用到的相关模板，供参考：