当前的工程项目只有kernel一个大模块，用户代码不应写在kernel中。 kernel中也会分为多个模块，这些模块共同组成系统架构，架构图如下所示。
v1.x 版本的架构图是前期的架构设计，只考虑了在 QEMU-LS2K1000 平台上的运行。为了使平台迁移更加容易，充分利用 C++ 的面向对象特性，对架构做出了重大更改，可见下图 架构图-v2.0 所示。
v2.0 架构以微内核、模块化为指导设计思想，力求各模块间松耦合，为适应嵌入式开发架构多样的特点，围绕硬件服务接口为中心，解耦硬件抽象层与内核模块。同时分离文件系统支持，进一步缩小内核规模，并参考 Linux VFS 思想，抽象文件系统接口，实现对多种文件系统的支持。
硬件服务抽象接口模块定义清晰地好了内核需要使用的服务接口，在进行平台移植时，可以只需要考虑接口实现，而无需关注内核实现。C++面向对象带来的高可读性，可以使实现硬件抽象层时更为简易。同时，硬件服务抽象接口还定义了通用设备接口，可以为硬件抽象层在实现具体的设备驱动时减少工作量。硬件服务抽象接口还包含了 SMP，这一支持包采用 C++ 的一些特性实现，目前已经包含了自旋锁的实现（实际上大量工作是由编译器保证的）。
同时本团队基于现有设计模式、编写的代码和v2.0架构的模块化设计原则，对RISC-V部分进行了针对性构建。硬件抽象层通过分离QEMU虚拟平台与K210物理硬件的驱动实现，统一异常管理框架和内存控制接口，利用C++多态特性封装平台差异，确保内核无需修改即可兼容不同环境。核心机制层面优化了SV39分页的TLB管理模块，基于RISC-V原子指令重构自旋锁与上下文切换逻辑，并通过汇编级代码实现用户态与内核态的高效切换。
外设驱动部分建立统一设备抽象模型，为K210的SD卡、SPI总线与QEMU的虚拟磁盘提供标准化操作接口，同时深度集成RustSBI固件生态，分别定制安全启动链。改进严格遵循硬件服务接口定义，仅需实现中断控制器、存储驱动等指定服务即可完成移植，验证了架构解耦设计的可迁移性。
此次适配延续了微内核与模块化思想，将平台相关代码限制在硬件抽象层，确保内核核心功能的跨架构一致性，为后续扩展异构计算支持奠定基础。
注意：
OS 使用 GCC 作为标准编译器，暂不支持其他编译器。编译使用 C++23 标准，因而 GCC 版本需求 13.1+。
- 新建模块到kernel/下，例如，smp.
- 在kernel/include/下新建smp.
3. 在kernel/Makefile中为submod变量添加smp.已经修改Makefile为递归识别所有目录和文件，不需要修改Makefile步骤1、2只是为了遵循开发规范，理论上kernel文件夹内的任何目录和c\c++以及汇编文件（c、cc、S后缀名）均会被识别