Linux设备驱动模型原理解析 (linux 设备驱动模型)
Linux 设备驱动模型是 Linux 内核开发中非常重要的一部分，它的作用是抽象硬件，为高级应用程序提供接口，同时也为驱动程序提供一种标准化的接口和规范。通过这种模型，我们可以像应用程序一样简单地和硬件进行交互，而不是需要直接操作硬件。
本文将对 Linux 设备驱动模型作出详细解析，包括它的原理、组织架构、部件和 API 接口等方面。我们希望能够帮助大家更全面的了解 Linux 的设备驱动模型，以及如何使用该模型来编写硬件驱动程序。
一. 设备驱动模型的原理
Linux 设备驱动模型的核心原理是将设备抽象成一个标准框架，通过该框架，应用程序和设备驱动程序可以更高效地交互。在设备驱动模型中，设备分为了两个主要部分：实体和驱动程序。实体是指设备的硬件实现，而驱动程序则是设备和应用程序之间的中间件，用于将硬件的实现和应用程序之间的通信桥梁联系起来。
驱动程序的功能是将系统中的设备管理起来，并向用户空间提供一些接口，以便于用户控制和使用系统中的设备。这其中，最重要的部分就是设备的注册和管理。在 Linux 设备驱动模型中，每个设备都有自己固定的属性，例如它的名字、类型、硬件编号等。通过这些属性，我们可以更方便快捷地管理系统中的设备，并调用其接口。
二. 设备驱动模型的组织架构
Linux 设备驱动模型由多个组件构成，在这些组件中，设备和驱动程序分别被分配到不同的分层中进行管理。下面是Linux 设备驱动模型中的各个组件：
1.总线 (Bus)
总线是对设备和 CPU 之间的物理连接进行抽象，以便于 Linux 内核将其高效地管理。总线是 Linux 设备驱动模型的之一层组件，因为它代表了最基本的硬件组件。
Linux 内核同时支持很多不同类型的总线，例如 PCI 总线、USB 总线、ACPI 总线、I2C 总线等，每种总线都有不同的特征和属性。在 Linux 内核中，总线是通过一个名为 bus_type 的结构体来描述的。
2.设备 (Device)
设备是总线上附加的实体，它代表了一个特定类型的硬件实现。在 Linux 设备驱动模型中，设备是第二层组件。每个设备都包括一个设备 ID（也称为硬件 ID）和一个设备节点
3.驱动程序 (Driver)
驱动程序也是 Linux 设备驱动模型中的重要组件，它负责把设备和应用程序之间的通信桥梁联系起来。驱动程序是设备的第三层组件，在 Linux 内核中，它由一个名为次设备对象 (sub-device) 的结构体来表示。
驱动程序的功能很多，包括初始化设备、分配 I/O 内存空间、处理中断、提供访问接口等。这其中，其中最重要的是设备的注册和管理，我们可以采用 sysfs 接口来操作设备的属性，采用 device driver 接口进行驱动程序的编写和注册。
4.总线驱动 (Bus Driver)
总线驱动是总线和设备之间的中间件，它将总线和设备的驱动程序连接起来，以便于更好地管理系统中的总线和设备对象。在 Linux 设备驱动模型中，总线驱动作为一个独立的组件存在，其主要功能是通过总线接口与设备驱动程序进行通信。总线驱动是通过一个名为 bus_driver 的结构体来描述的。
Linux 设备驱动模型是一个非常复杂的结构，它由多个部件组合而成。每个部件都有自己特定的功能，并与其他部件相互关联，共同构建一个健全的设备驱动模型。
三. 设备驱动模型的 API 接口
Linux 设备驱动模型提供了许多 API 接口，我们可以利用这些接口来操作和管理系统中的各种设备和驱动程序。以下是一些常用的 API 接口：
1.设备驱动程序接口
设备驱动程序接口指的是与设备驱动程序相关的 API 接口，主要包括 “注册驱动程序”、”注销驱动程序”、“内存分配接口”、“挂起接口”、“中断处理接口”、“设备属性操作接口等。
在 Linux 设备驱动模型中，驱动程序注册是一个非常重要的过程。它帮助我们把设备的驱动程序注册到 Linux 内核中去，以便系统可以识别、管理设备。注册驱动程序的过程可以调用 register_chrdev() 函数来实现。
2.设备节点接口
设备节点接口是通过 sysfs 接口在设备树中创建设备节点的接口。它帮助我们更方便地操作设备属性和系统信息，并提供了一种标准化的数据交换格式。
在设备节点接口中，我们可以使用 sysfs 接口来操作设备节点的属性，例如写入和读取设备属性、设定设备属性等。
3.总线驱动程序接口
总线驱动程序是与总线驱动相关的 API 接口，它可以帮助我们更好地管理系统中的总线和设备对象。
总线驱动程序接口提供了一些函数，例如总线驱动程序注册函数、设备驱动程序绑定函数、设备驱动程序解绑函数等，这些函数可以在驱动程序的编写和注册中加以使用，以帮助我们更好地管理系统设备。
本文主要介绍了 Linux 设备驱动模型的原理、组织架构和 API 接口。通过这些知识，我们已经可以更加深入地了解 Linux 设备驱动模型，并在实际中更好地操作和管理系统中的各种设备和驱动程序。希望这篇文章对大家有所帮助。
相关问题拓展阅读：
linux的内核模块都在哪里放着啊
一个完整的Linux内核一般由5部分组成，它们分别是内存管理、进程管理、进程间通信、虚拟文件系统和网络接口。1、内存管理内存管理主要完成的是如何合理有效地管理整个系统的物理内存，同时快速响应内核各个子系统对内存分配的请求。Linux内存管理支持虚拟内存，而多余出的这部分内存就是通过磁盘申请得到的，平时系统只把当前运行的程序块保留在内存中，其他程序块则保留在磁盘中。薯返在内存紧缺时，内存管理负责在磁盘和内存间交换程序块。2、进程管理进程管理主要盯手举控制系统进程对CPU的访问。当需要某个进程运行时，由进程调度器根据基于优先级的调度算法启动新的进程。：Linux支持多任务运行，那么如何在一个单CPU上支持多任务呢？这个工作就是由进程调度管理来凯碧实现的。在系统运行时，每个进程都会分得一定的时间片，然后进程调度器根据时间片的不同，选择每个进程依次运行，例如当某个进程的时间片用完后，调度器会选择一个新的进程继续运行。由于切换的时间和频率都非常的快，由此用户感觉是多个程序在同时运行，而实际上，CPU在同一时间内只有一个进程在运行，这一切都是进程调度管理的结果。3、进程间通信进程间通信主要用于控制不同进程之间在用户空间的同步、数据共享和交换。由于不用的用户进程拥有不同的进程空间，因此进程间的通信要借助于内核的中转来实现。一般情况下，当一个进程等待硬件操作完成时，会被挂起。当硬件操作完成，进程被恢复执行，而协调这个过程的就是进程间的通信机制。4、虚拟文件系统Linux内核中的虚拟文件系统用一个通用的文件模型表示了各种不同的文件系统，这个文件模型屏蔽了很多具体文件系统的差异，使Linux内核支持很多不同的文件系统，这个文件系统可以分为逻辑文件系统和设备驱动程序：逻辑文件系统指Linux所支持的文件系统，例如ext2、ext3和fat等；设备驱动程序指为每一种硬件控制器所编写的设备驱动程序模块。5、网络接口网络接口提供了对各种网络标准的实现和各种网络硬件的支持。网络接口一般分为网络协议和网络驱动程序。网络协议部分负责实现每一种可能的网络传输协议。网络设备驱动程序则主要负责与硬件设备进行通信，每一种可能的网络硬件设备都有相应的设备驱动程序。
Linux 磁盘IO
磁盘结构与数据存储方式, 数据是如何存储的，又通过怎样的方式被访问？
机械硬盘主要由磁盘盘片、磁头、主轴与传动轴等组成；数据就存放在磁盘盘片中
现代硬盘寻道都是采用CHS( Cylinder Head Sector )的方式，硬盘读取数据时，读写磁头沿径向移动，移到要读取的扇区所在磁道的上方，这段时间称为
寻道时间(seek time)
。
因读写磁头的起始位置与目标位置之间的距离不同，寻道时间也不同
。磁头到达指定磁道后，然后通过盘片的旋转，使得要读取的扇区转到读写磁头的下方，这段时间称为
旋转延迟时间(rotational latencytime)
。然后再读写数据，读手租写数据也需要时间，这段时间称为
传输时间(transfer time)
。
固态硬盘主要由主控芯片、闪存颗粒与缓存组成；数据就存放在闪存芯片中
通过主控芯片进行寻址， 因为毕好兆是电信号方式， 没有任何物理结构， 所以寻址速度非常快且与数据存储位置无关
如何查看系统IO状态
查看磁盘空间
调用 open , fwrite 时到底发生了什么?
在一个IO过程中，以下5个API/系统调用是必不可少的
Create 函数用来打开一个文件，如果该文件不存在，那么需要在磁盘上创建该文件
Open 函数用于打开一个指定的文件。如果在 Open 函数中指定 O_CREATE 标记，那么 Open 函数同样可以实现 Create 函数的功能
Clos e函数用于释放文件句柄
Write 和 Read 函数用于实现文件的读写过程
O_SYNC (先写缓存, 但是需要实际落袜粗盘之后才返回, 如果接下来有读请求, 可以从内存读 ), write-through
O_DSYNC (D=data, 类似O_SYNC, 但是只同步数据, 不同步元数据)
O_DIRECT (直接写盘, 不经过缓存)
O_ASYNC (异步IO, 使用信号机制实现, 不推荐, 直接用aio_)
O_NOATIME (读取的时候不更新文件 atime(access time))
sync() 全局缓存写回磁盘
fsync() 特定fd的sync()
fdatasync() 只刷数据, 不同步元数据
mount noatime(全局不记录atime), re方式(只读), sync(同步方式)
一个IO的传奇一生 这里有一篇非常好的资料，讲述了整个IO过程；
下面简单记录下自己的理解的一次常见的Linux IO过程， 想了解更详细及相关源码，非常推荐阅读上面的原文
Linux IO体系结构
Superblock
超级描述了整个文件系统的信息。为了保证可靠性，可以在每个块组中对superblock进行备份。为了避免superblock冗余过多，可以采用稀疏存储的方式，即在若干个块组中对superblock进行保存，而不需要在所有的块组中都进行备份
GDT 组描述符表
组描述符表对整个组内的数据布局进行了描述。例如，数据块位图的起始地址是多少？inode位图的起始地址是多少？inode表的起始地址是多少？块组中还有多少空闲块资源等。组描述符表在superblock的后面
数据块位图
数据块位图描述了块组内数据块的使用情况。如果该数据块已经被某个文件使用，那么位图中的对应位会被置1，否则该位为0
Inode位图
Inode位图描述了块组内inode资源使用情况。如果一个inode资源已经使用，那么对应位会被置1
Inode表
（即inode资源）和数据块。这两块占据了块组内的绝大部分空间，特别是数据块资源
一个文件是由inode进行描述的。一个文件占用的数据块block是通过inode管理起来的
。在inode结构中保存了直接块指针、一级间接块指针、二级间接块指针和三级间接块指针。对于一个小文件，直接可以采用直接块指针实现对文件块的访问；对于一个大文件，需要采用间接块指针实现对文件块的访问
最简单的调度器。它本质上就是一个链表实现的
fifo
队列，并对请求进行简单的
合并
处理。
调度器本身并没有提供任何可以配置的参数
读写请求被分成了两个队列， 一个用访问地址作为索引，一个用进入时间作为索引，并且采用两种方式将这些request管理起来；
在请求处理的过程中，deadline算法会优先处理那些访问地址临近的请求，这样可以更大程度的减少磁盘抖动的可能性。
只有在有些request即将被饿死的时候，或者没有办法进行磁盘顺序化操作的时候，deadline才会放弃地址优先策略，转而处理那些即将被饿死的request
deadline算法可调整参数
read_expire
: 读请求的超时时间设置(ms)。当一个读请求入队deadline的时候，其过期时间将被设置为当前时间＋read_expire，并放倒fifo_list中进行排序
write_expire
:写请求的超时时间设置(ms)
fifo_batch
:在顺序（sort_list）请求进行处理的时候，deadline将以batch为单位进行处理。每一个batch处理的请求个数为这个参数所限制的个数。在一个batch处理的过程中，不会产生是否超时的检查，也就不会产生额外的磁盘寻道时间。这个参数可以用来平衡顺序处理和饥饿时间的矛盾，当饥饿时间需要尽可能的符合预期的时候，我们可以调小这个值，以便尽可能多的检查是否有饥饿产生并及时处理。增大这个值当然也会增大吞吐量，但是会导致处理饥饿请求的延时变长
writes_starved
:这个值是在上述deadline出队处理之一步时做检查用的。用来判断当读队列不为空时，写队列的饥饿程度是否足够高，以时deadline放弃读请求的处理而处理写请求。当检查存在有写请求的时候，deadline并不会立即对写请求进行处理，而是给相关数据结构中的starved进行累计，如果这是之一次检查到有写请求进行处理，那么这个计数就为1。如果此时writes_starved值为2，则我们认为此时饥饿程度还不足够高，所以继续处理读请求。只有当starved >= writes_starved的时候，deadline才回去处理写请求。可以认为这个值是用来平衡deadline对读写请求处理优先级状态的，这个值越大，则写请求越被滞后处理，越小，写请求就越可以获得趋近于读请求的优先级
front_merges
:当一个新请求进入队列的时候，如果其请求的扇区距离当前扇区很近，那么它就是可以被合并处理的。而这个合并可能有两种情况，一个是向当前位置后合并，另一种是向前合并。在某些场景下，向前合并是不必要的，那么我们就可以通过这个参数关闭向前合并。默认deadline支持向前合并，设置为0关闭
在调度一个request时，首先需要选择一个一个合适的cfq_group。Cfq调度器会为每个cfq_group分配一个时间片，当这个时间片耗尽之后，会选择下一个cfq_group。每个cfq_group都会分配一个vdisktime，并且通过该值采用红黑树对cfq_group进行排序。在调度的过程中，每次都会选择一个vdisktime最小的cfq_group进行处理。
一个cfq_group管理了7棵service tree，每棵service tree管理了需要调度处理的对象cfq_queue。因此，一旦cfq_group被选定之后，需要选择一棵service tree进行处理。这7棵service tree被分成了三大类，分别为RT、BE和IDLE。这三大类service tree的调度是按照优先级展开的
通过优先级可以很容易的选定一类Service tree。当一类service tree被选定之后，采用service time的方式选定一个合适的cfq_queue。每个Service tree是一棵红黑树，这些红黑树是按照service time进行检索的，每个cfq_queue都会维护自己的service time。分析到这里，我们知道，cfq算法通过每个cfq_group的vdisktime值来选定一个cfq_group进行服务，在处理cfq_group的过程通过优先级选择一个最需要服务的service tree。通过该Service tree得到最需要服务的cfq_queue。该过程在 cfq_select_queue 函数中实现
一个cfq_queue被选定之后，后面的过程和deadline算法有点类似。在选择request的时候需要考虑每个request的延迟等待时间，选择那种等待时间最长的request进行处理。但是，考虑到磁盘抖动的问题，cfq在处理的时候也会进行顺序批量处理，即将那些在磁盘上连续的request批量处理掉
cfq调度算法的参数
back_seek_max
:磁头可以向后寻址的更大范围，默认值为16M
back_seek_penalty
:向后寻址的惩罚系数。这个值是跟向前寻址进行比较的
fifo_expire_async
:设置异步请求的超时时间。同步请求和异步请求是区分不同队列处理的，cfq在调度的时候一般情况都会优先处理同步请求，之后再处理异步请求，除非异步请求符合上述合并处理的条件限制范围内。当本进程的队列被调度时，cfq会优先检查是否有异步请求超时，就是超过fifo_expire_async参数的限制。如果有，则优先发送一个超时的请求，其余请求仍然按照优先级以及扇区编号大小来处理
fifo_expire_sync
:这个参数跟上面的类似，区别是用来设置同步请求的超时时间
slice_idle
:参数设置了一个等待时间。这让cfq在切换cfq_queue或service tree的时候等待一段时间，目的是提高机械硬盘的吞吐量。一般情况下，来自同一个cfq_queue或者service tree的IO请求的寻址局部性更好，所以这样可以减少磁盘的寻址次数。这个值在机械硬盘上默认为非零。当然在固态硬盘或者硬RAID设备上设置这个值为非零会降低存储的效率，因为固态硬盘没有磁头寻址这个概念，所以在这样的设备上应该设置为0，关闭此功能
group_idle
:这个参数也跟上一个参数类似，区别是当cfq要切换cfq_group的时候会等待一段时间。在cgroup的场景下，如果我们沿用slice_idle的方式，那么空转等待可能会在cgroup组内每个进程的cfq_queue切换时发生。这样会如果这个进程一直有请求要处理的话，那么直到这个cgroup的配额被耗尽，同组中的其它进程也可能无法被调度到。这样会导致同组中的其它进程饿死而产生IO性能瓶颈。在这种情况下，我们可以将slice_idle ＝ 0而group_idle ＝ 8。这样空转等待就是以cgroup为单位进行的，而不是以cfq_queue的进程为单位进行，以防止上述问题产生
low_latency
:这个是用来开启或关闭cfq的低延时（low latency）模式的开关。当这个开关打开时，cfq将会根据target_latency的参数设置来对每一个进程的分片时间（slice time）进行重新计算。这将有利于对吞吐量的公平（默认是对时间片分配的公平）。关闭这个参数（设置为0）将忽略target_latency的值。这将使系统中的进程完全按照时间片方式进行IO资源分配。这个开关默认是打开的
target_latency
:当low_latency的值为开启状态时，cfq将根据这个值重新计算每个进程分配的IO时间片长度
quantum
:这个参数用来设置每次从cfq_queue中处理多少个IO请求。在一个队列处理事件周期中，超过这个数字的IO请求将不会被处理。这个参数只对同步的请求有效
slice_sync
:当一个cfq_queue队列被调度处理时，它可以被分配的处理总时间是通过这个值来作为一个计算参数指定的。公式为： time_slice = slice_sync + (slice_sync/5 * (4 – prio)) 这个参数对同步请求有效
slice_async
:这个值跟上一个类似，区别是对异步请求有效
slice_async_rq
:这个参数用来限制在一个slice的时间范围内，一个队列最多可以处理的异步请求个数。请求被处理的更大个数还跟相关进程被设置的io优先级有关
通常在Linux上使用的IO接口是同步方式的，进程调用 write / read 之后会阻塞陷入到内核态，直到本次IO过程完成之后，才能继续执行，下面介绍的异步IO则没有这种限制，但是当前Linux异步IO尚未成熟
目前Linux aio还处于较不成熟的阶段，只能在 O_DIRECT 方式下才能使用(glibc_aio)，也就是无法使用默认的Page Cache机制
正常情况下，使用aio族接口的简要方式如下：
io_uring 是 2023 年 5 月发布的 Linux 5.1 加入的一个重大特性 —— Linux 下的全新的异步 I/O 支持，希望能彻底解决长期以来 Linux AIO 的各种不足
io_uring 实现异步 I/O 的方式其实是一个生产者-消费者模型:
逻辑卷管理
RAID0
RAID1
RAID5（纠错）
条带化
Linux系统性能调整：IO过程
Linux的IO调度
一个IO的传奇一生
理解inode
Linux 文件系统是怎么工作的？
Linux中Buffer cache性能问题一探究竟
Asynchronous I/O and event notification on linux
AIO 的新归宿：io_uring
关于linux 设备驱动模型的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
