📚 课程目录第1章依赖管理概述

1. 依赖管理概述

驱动依赖，说白了就是你的驱动程序在运行过程中，需要「依靠」哪些东西才能正常工作。

我刚开始做驱动开发时，总觉得写驱动就是操作硬件寄存器。后来踩了不少坑才明白——驱动从来不是孤立的。它依赖操作系统、依赖其他驱动、依赖硬件资源、甚至依赖特定的固件版本。

举个例子，一个简单的 USB 摄像头驱动，它依赖什么？

我在项目中遇到过最头疼的情况：一个网卡驱动在 5.4 内核上跑得好好的，换到 5.10 内核就崩了。查了半天，原来是内核的 NAPI 接口变了，驱动没跟上。这就是典型的 API 依赖问题。

  驱动依赖的本质：驱动不是独立存在的，它是一张「依赖网」上的一个节点。这张网上的任何一根线断了，驱动都可能罢工。

你可能会问：「依赖就依赖呗，我写代码时注意点不就行了？」

嗯，如果只是三五个驱动的小项目，确实可以靠脑子记。但现实中的嵌入式系统，动辄几十上百个驱动。你想想看，一个完整的 Linux 内核就有几千个驱动模块。这时候没有依赖管理，就是一场灾难。

我经历过一次惨痛的教训。当时做一个车载信息娱乐系统，集成了触摸屏、蓝牙、Wi-Fi、GPS 等多个驱动。开发阶段各搞各的，集成时才发现：

结果就是系统启动时各种报错，花了整整一周才把所有依赖理清楚。从那以后，我养成了一个习惯：写驱动之前，先把依赖图画出来。

依赖管理解决的核心问题有三个：

我的经验：依赖管理不是「出了问题再修」，而是「写代码时就规划好」。每次提交代码前，我都会问自己三个问题：这个驱动依赖什么？依赖的版本是多少？如果依赖不存在会怎样？

依赖管理到底要达成什么目标？我总结为三点：

目标	说明	我的实践
可预测性	给定相同的依赖环境，驱动行为一致	用容器或虚拟机固定开发环境，避免「在我机器上能跑」
可追溯性	能清楚知道每个依赖的来源和版本	维护一个 dependencies.txt 文件，记录所有依赖及其版本
可复现性	换一台机器、换一个时间，还能构建出同样的驱动	使用 Makefile 自动检查依赖，不满足就报错

说白了，依赖管理的终极目标就是：让驱动在任何环境下都能稳定工作，而不是靠运气。

避坑指南：我曾经在一个项目里，因为依赖管理没做好，导致生产环境上的驱动和开发环境不一致。结果产品出货后，有 30% 的设备启动时蓝屏。排查了三天才发现是固件版本不对。从那以后，我强制团队使用版本锁定的依赖管理方案。

依赖管理的知识体系，可以用下面这张图来概括：

这张图清晰地展示了依赖管理的核心：三个目标（可预测、可追溯、可复现）驱动着我们对四种依赖类型（内核 API、硬件资源、其他驱动、固件配置）进行管理。

在实际项目中，我通常这样操作：

  一句话总结：依赖管理不是额外的工作，而是驱动开发的一部分。把依赖理清楚了，后面集成、调试、维护都能省下大把时间。