统信UOS驱动解耦方案

文章目录

前言
一、驱动兼容方案说明
二、常见驱动分离指导

在这里插入图片描述

前言

驱动解耦方案主要是协助厂商可按照UOS提供的驱动开发标准与样例开发和更新驱动，和UOS的研发计划解耦。同时厂商提供的驱动，可通过集成到ISO镜像仓库中、上传到驱动平台等方式供终端用户使用和更新。

一、驱动兼容方案说明

方案概述

目的

当前UOS的内核的很多需求是合入第三方驱动的代码到主线，由于第三方驱动的代码提供的时间不可控，并且存在质量风险，这就导致了内核版本的发布严重依赖于第三方驱动。
为了满足UOS内核的版本按时发布，并且可以快速集成第三方的驱动，UOS提出了驱动解耦方案。

希望达成目的：

厂商可按照UOS整理和提供的驱动开发标准与样例开发和更新驱动，不需要通过与UOS的研发计划进行耦合。
厂商提供的驱动，可通过集成到ISO镜像仓库中、上传到驱动平台等方式供终端用户使用和更新。

技术架构

UOS的内核和第三方驱动的关系入下图：

在这里插入图片描述
备注：

用户态驱动在此特指和硬件相关的用户态程序或者库文件，比如显卡的umd,指纹识别等。
vmlinux里面的驱动模块是不能被覆盖的，UOS kernel Modules或者UOS user modules drivers可以被Vendor Modules覆盖。覆盖的方式需要采用DKMS的方式来进行。为了满足kernel和vendor module厂商开发之间相互独立，我们需要在kernel和vendor module之间确定一个稳定的接口，即KABI。

厂商驱动适配方案

DKMS适配方案

dkms 介绍

DKMS是Linux内核模块的基本框架之一，用于支持内核设备驱动程序的自动重建和动态机制，对驱动程序的开发、测试和检验进行了系统性的支持，也便于用户安装所需的驱动程序。DKMS源代码一般不在Linux内核源代码树。当新的内核安装时，DKMS支持的内核设备驱动程序到时会自动重建。 DKMS可以用在两个方向：如果一个新的内核版本安装，自动编译所有的模块，或安装新的模块（驱动程序）在现有的系统版本上，而不需要任何的手动编译或预编译软件包需要。

DKMS的目的是让依赖内核的模块源码独立出来以便升级内核时候可以容易地重新建立。这也使得Linux驱程编写人员能够尽快的提供他们的驱动而不用等待新版本的Linux内核发布，同时也打消了用户对模块能否在新内核上面重新编译的疑虑。

本驱动模块兼容方案，重点依托DKMS技术框架。厂商可根据DKMS框架进行驱动开发。

kabi 介绍

为了满足 kernel 和 vendor module 厂商开发之间相互独立，我们需要在 kernel 和 vendor module 之间确定一个稳定的接口，这个就是 KABI。

KABI (Kernel Application Binary Interface) 兼容，即内核与驱动的二进制兼容。就是驱动无需重新编译，即可在新内核上安装使用。如果驱动用到的接口都是兼容的，那么驱动就可以不用重新编译就可以在新版本安装使用。

统信会基于目前所有二进制驱动，获取其涉及到的所有API形成清单，并确保该清单内的所有API，在Kernel变更时不受影响。

whitelist介绍

理想的情况下，内核最好是将所有export symbol都加入到KMI中，保证它们全部不发生变化。但实际开发维护中这很难做到，所以引入了whitelist机制。

whitelist机制是一种有限保证机制：内核只保证在whitelist内的符号，在内核版本升级时不发生变化，而不对其他符号作出兼容性保证。换而言之，KMI中只包含whitelist中的符号。

whitelist在发布后保持稳定，只允许增加新的符号，不允许删除已有的符号。

dkms方案适配流程

dkms的使用流程可以用下图简单表示：

在这里插入图片描述

dkms add：将内核模块源代码添加到 dkms 中，使其可以自动构建和安装
dkms build：使用 dkms 构建内核模块
dkms install：使用 dkms 安装内核模块。
dkms status：显示已安装的内核模块及其状态。
dkms mkdeb：创建 Debian 软件包。
dkms remove：从dkms中删除内核模块。

驱动适配注意事项

KABI的兼容性
KMI，Kernel Module Interface，可简单理解为内核中导出的可供其它模块使用的接口。显卡驱动的适配中，统信提供内核的KABI以及KABI白名单，统信和厂商要共同维护KABI的稳定，KABI白名单的符合不能破坏（例如厂商驱动或者统信修改DRM框架的公共接口）。
污染内核
如果外设的内核驱动模块做为专有模块、不兼容GPL，内核就提示taints，可能的影响包括不受社区欢迎、某些调试API不可用等。功能可能不受影响，但是系统处于一个不好的状态。
功能冲突
外设厂商适配是在基础环境下完成的，和最终集成的系统环境必然存在差异。新的适配软件集成过程中，存在与现有系统功能、软件发生冲突的风险。
通用性
外设厂商完成适配的功能验证，如果存在非通用型部分（比如内部调用库的存放、权属设定、特殊的配置文件），那么在多CPU架构、多系统版本的操作系统上存在通用性问题，最坏情况是一个架构、一个系统版本做一次适配。目标是同源异构。