1. 课程导论：Linux驱动通信概览
1.1 用户态与内核态隔离
Linux 操作系统通过硬件提供的特权级机制，将系统运行空间划分为用户态（User Space）和内核态（Kernel Space）。这种隔离是系统安全与稳定的基石。
- 用户态：应用程序运行在受限的 Ring 3 级别，无法直接访问硬件资源或内核数据结构。任何对关键资源的操作都必须通过系统调用陷入内核。
- 内核态：操作系统内核运行在最高特权级 Ring 0，拥有对硬件、内存、进程等所有资源的完全控制权。设备驱动驻留在内核态。
核心矛盾：驱动在内核态管理硬件，而应用程序在用户态运行。如何高效、安全地将数据和控制信息在两者之间传递，是驱动开发的核心挑战。
1.2 驱动与用户态通信概览
Linux 内核提供了多种机制来实现用户态与内核态驱动之间的数据交换。选择合适的通信方式，直接影响系统的性能、实时性和代码复杂度。
| 通信方式 | 数据量 | 实时性 | 典型场景 |
|---|---|---|---|
| /proc 文件系统 | 小 | 低 | 调试信息、内核参数读取 |
| sysfs | 小 | 低 | 设备属性、电源管理状态 |
| netlink | 中 | 中 | 网络配置、内核事件通知 |
| ioctl | 小-中 | 高 | 设备控制、参数配置、命令下发 |
| mmap | 大 | 极高 | 视频帧采集、高速数据采集、共享内存 |
课程聚焦：本课程将深入讲解 ioctl 和 mmap 两种最常用、最强大的通信机制。ioctl 擅长“控制”，mmap 擅长“批量数据传输”，两者结合几乎可以覆盖所有驱动通信需求。
1.3 ioctl 与 mmap 核心价值对比
ioctl 和 mmap 在设计哲学、使用方式和性能特征上存在本质差异。理解这些差异，是正确选择通信方式的前提。
1.4 选择策略：何时用 ioctl，何时用 mmap？
在实际项目中，ioctl 和 mmap 并非互斥，而是互补关系。一个典型的驱动通常会同时提供这两种接口。
常见误区：不要试图用 ioctl 传输大块数据（如 > 1MB），这会导致频繁的系统调用和内存拷贝，严重降低性能。同样，不要用 mmap 来实现简单的设备开关控制，这会浪费宝贵的虚拟地址空间。
推荐组合策略
- 控制面：ioctl — 用于设备初始化、参数配置、启动/停止、状态查询等控制类操作。
- 数据面：mmap — 用于视频帧、音频流、雷达点云、高速 ADC 数据等需要持续、大批量传输的场景。
- 事件通知：poll/select/epoll — 配合 ioctl 或 mmap 使用，当数据就绪或设备状态变化时通知用户态。
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 设置摄像头帧率 | ioctl | 小数据量控制命令，需要即时响应 |
| 采集 1080p 视频帧 | mmap | 每帧约 6MB，零拷贝避免性能瓶颈 |
| 读取传感器 ID | ioctl | 仅需读取几个字节的寄存器 |
| 传输雷达点云数据 | mmap | 每秒百万级点云数据，必须零拷贝 |
| 动态调整 DMA 缓冲区大小 | ioctl | 需要向内核传递复杂参数并获取结果 |