devMaster: 新一代设备管理器¶
认识Linux的设备管理器和devMaster¶
设备管理器承担着设备热插拔处理、设备节点创建与更新等操作，是系统初始化流程中必不可少的一个环节。devMaster作为sysMaster的设备管理模块，是支撑系统快速启动、保证系统功能正常运行的重要功能组件。
设备管理器作为链接用户态软件与底层物理设备的桥梁，支撑着许多用户态基础软件，比如lvm2、NetworkManager等等，是系统用户态的核心组件之一。Linux的设备管理机制划分为内核态和用户态：内核承担设备发现的功能，并通过sysfs下的kobject提供设备信息查询以及与内核交互的接口，另外内核会通过netlink通知用户态进程，或者使用hotplug机制直接调用用户态程序；用户态设备管理器，比如主流的udev(userspace device)，监听内核上报的设备事件，并根据设备属性执行一系列灵活的管理动作，总体来看具备以下几类功能：
- 管理静态设备节点：但是随着
devtmpfs在2009年收录进Linux 2.6.32，静态设备节点由内核进行创建，令一般启动程序不必等待udev。 - 设备命名映射：内核创建的设备节点，比如
/dev/sda，往往不具备直观可理解的名称，而udev可以提供一种类似DNS的命名映射机制，将设备映射到固定可理解的名称上。 - 网卡保序：服务器可能通过板载集成、
PCIe插槽扩展等方式，持有多块网卡，而内核发现并命名网卡的编号具有随机性，导致网卡节点的名称无法对应物理顺序，udev通过读取网卡所在的PCI总线号、插槽索引等固定信息，将网卡名称固定到特定编号上。 - 控制设备节点的权限、动态分配设备的主/次设备号等等。
在不同的应用场景下，设备管理器提供的能力也会相应地扩展或裁剪。例如，在嵌入式和移动终端场景下，设备数量和种类相对固定且计算资源有限，因此设备管理器更趋向于功能精简和场景定制化，比如mdev仅支持热插拔时的设备节点更新、vold仅提供可插拔存储设备的挂载卸载功能等。而在通用服务器和桌面OS上，由于物理设备种类丰富、数量众多，且上层应用的业务逻辑更加复杂，这要求设备管理器提供更高的灵活性和可扩展性。
| 设备管理器 | 应用场景 | 说明 | 热插拔 | 并发处理 | 支持通用设备 | 策略定制 | 更新同步 |
|---|---|---|---|---|---|---|---|
android vold |
移动终端设备 | 支持对可插拔存储设备的挂载和卸载管理 | ✔️ | ✔️ | |||
busybox mdev |
嵌入式设备 | 利用内核的hotplug回调机制触发设备节点更新 |
✔️ | ✔️ | ✔️ | ||
systemd udev |
服务器/桌面PC |
主流的用户态设备管理器，具备良好的可扩展性，支持上层软件定制设备处理规则 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
udev作为极具代表性的通用OS用户态设备管理器，基本占据了主流的Linux发行版平台。相比于早期内核态的设备管理方案devfs/devtmpfs，udev提供更灵活、更强大的定制化设备处理能力，比如创建设备软链接、持久化命名、网卡保序等等，使得上层软件可以更灵活、更方便地实现业务逻辑。但是随着HAL(hardware abstraction layer)和udev的功能整合，以及后续udev与systemd项目的合并，udev的功能越来越臃肿，越来越依赖于systemd的初始化系统生态，这违背了软件设计的分层解耦原则，导致其他软件被强行绑定到systemd生态中。
sysMaster项目作为openEuler对新一代系统初始化和服务管理系统的探索，集成设备管理功能是必不可少的。devMaster作为sysMaster的设备管理组件，一方面支撑sysMaster的快速启动以及用户态软件的生态兼容，另一方面通过对Linux生态下主流设备管理方案的现状和优劣进行了总结和思考，希望提供一种分层解耦、可扩展性强、面向通用OS的设备管理能力。
devMaster的愿景与原理¶
作为系统初始化以及常态运行下关键的系统功能，用户态设备管理器需要具备极高的可靠性、运行效率以及可扩展性，是支撑虚拟机/物理机启动与运行必不可少的系统组件。因此，devMaster的目标主要包含以下几点：
- 消除系统层面的内存安全问题，降低高并发场景下的设备竞争的负面影响，提高设备管理器的可靠性和鲁棒性。
- 南向兼容
Linux和鸿蒙微内核生态，北向兼容现有用户态软件的udev规则配置和libudev动态库接口调用，支持无缝迁移devMaster工具链。 - 采用分层解耦的软件设计，保证设备管理器的轻量级、高效率，同时具备极致的可扩展能力。
devMaster的软件架构遵循高内聚、低耦合的设计原则，保证各组件职责独立，提高软件可复用、可替换、可扩展能力，降低开发维测成本。devMaster主要包含四部分组件，分为常驻进程devmaster、客户端工具devctl、对外库以及兼容性工具。devMaster使用Rust语言编写，能够原生消除内存安全类问题。devMaster的核心原理如下：
- 事件驱动：实时监听设备热插拔事件，并利用队列分级技术，满足事件高并发场景，缓解设备竞争问题，同时使用
worker池机制支撑事件并发处理能力，提高事件处理的吞吐量，支撑秒级启动能力。 - 机制与策略分离：通过将事件处理的行为定义在外部规则文件中，避免设备处理逻辑硬编码，并支持设备规则按需组合、定制、裁剪，提供灵活、强大的可扩展能力。
- 可维可测：通过客户端工具
devctl提供对devmaster的用户端控制接口，提升devmaster的可维可测能力，并兼容udevadm选项，支持用户使用习惯的平滑迁移。 Rust工具链：对外库提供开发者获取硬件设备信息以及与devmaster交互的对外接口，完善Rust语言在设备管理领域的三方库与工具链。- 生态兼容：提供完善的南北向兼容性工具，比如
udev规则转译工具、对外库的Rust2C接口迁移、特殊设备组件等，支持udev到devMaster生态的无缝迁移。依托欧拉鸿蒙生态，打通嵌入式/物理机/虚拟机OS全场景。
总的来说，devMaster的设计旨在简化系统架构，并通过多项关键技术确保设备管理器具备机制的可扩展性、可靠性、可维可测能力、软件性能以及生态兼容能力，是一款非常有价值的设备管理工具。
devMaster全景图¶
今年sysMaster将聚焦系统快速启动能力，而devMaster作为支撑快速启动的核心功能组件，在2022年12月份完成了顶层设计并规划了预计3个季度的开发路标，2023年1月份期间devMaster在sysMaster项目中贡献了第一次提交并自此开始了正式的编码工作。devMaster目前仍处于快速迭代，在第一个季度中，我们已完成了事件驱动的软件运行框架编码，包括事件监听模块、事件队列模块和worker池，另外我们也完成了libdevice库的主体功能以及devctl部分子命令的开发。在第二个季度中，我们重点投入规则处理模块，目前已支持规则加载以及部分规则执行功能，并且将在后续引入devctl的用户调测接口。第三个季度，我们计划完成余下的诸如配置管理、控制管理、节点监控、兼容性工具等特性编码，并逐步嵌入initramfs启动以及主系统初始化流程，支撑物理盘、逻辑卷、PXE等不同系统启动需求，最终覆盖物理机、虚拟机等全场景的快速启动能力。
创建日期: March 24, 2023