总线驱动设备

Linux设备模型使用了三个数据结构分别来描述总线、设备和驱动。所有的设备和对应的驱动都必须挂载在某一个总线上，通过总线，可以绑定设备和驱动。

这个属于分离的思想，将设备和驱动分开管理。

总线是处理器和设备之间的通道。总线有多种类型，每种总线可以挂载多个设备。

在设备模型中，所有的设备都通过总线相连，以总线来管理设备和驱动函数。总线有bus_type结构表示。

设置总线的属性后，会在对应的总线目录下增加了一个新的文件，通过对该文件的读写访问，触发相应的函数 *** 作，从而实现/sys/的文件接口与内核设备模型的数据交互。

bus_attribute中有两个函数指针，show和store。

使用宏BUS_ATTR

BUS_ATTR(_name, _mode, _show, _store)

该宏会定义一个名叫bus_attr__name的bus_attibute的结构，并且成员name设置为_name，文件权限mode设置为_mode，两个函数调用分别人show和store。

使用以下调用：

该函数失败时返回错误号。

一旦调用该函数，会就在指定bus总线的目录下新建一个名叫_name的文件

驱动程序是在CPU运行时，提供 *** 作的软件接口。所有的设备必须有与之配套驱动程序才能正常工作。一个驱动程序可以驱动多个类似或者完全不同的设备。

和设备不一样的是，在注册驱动函数是必须指定该驱动函数对应的总线，因为驱动函数注册成功后，会存放在对应总线的driver目录下，如果没有总线，注册当然会失败。

1、定义结构体device_driver。

2、调用注册函数：

设备就是连接在总线上的物理实体。设备是有功能之分的。具有相同功能的设备被归到一个类，如输入设备（鼠标，键盘，游戏杆等）。

linux系统中每个设备都用一个device结构的表示

注册一个完整的device结构前，至少定义parrent、bus_id、bus和release成员

1、定义结构体device。

2、调用注册函数：

使用宏DEVICE_ATTR

DRIVER_ATTR(_name, _mode, _show, _store)

该宏会定义一个名叫driver_attr__name的driver_attibute的结构，并且成员name设置为_name，文件权限mode设置为_mode，两个函数调用分别人show和store。

一旦调用该函数，会就在指定dev设备的目录下新建一个名叫_name的文件.

设备模型是2.6内核新引入的特征。设备模型提供了一个独立的机制专门来表示设备，并描述其在系统中的拓扑结构。

sys下有如下目录

block：用于管理块设备，系统中的每一个块设备会在该目录下对应一个子目录。

bus：用于管理总线，每注册一条总线，在该目录下有一个对应的子目录。

其中，每个总线子目录下会有两个子目录：devices和drivers。devices包含里系统中所有属于该总线的的设备。drivers包含里系统中所有属于该总线的的驱动。

class：将系统中的设备按功能分类。

devices：该目录提供了系统中设备拓扑结构图。

dev：该目录已注册的设备节点的视图。

class/net/eth0的路径其实就是devices目录中一个网卡设备的软连接。

sys中的其他目录都是将device目录下的数据加以转换加工而得。上面的图中，将usb设备归类到bus总线上，又把它归类到class。正是在sys中有很多这样的结构，内核就有一个完整而且复杂的拓扑结构图。

而维护这些关系的结构体就包括kobject、kset、ktype和subsystem等数据结构

kobject是一个对象的抽象，它用于管理对象。每个kobject对应着sysfs中的一个目录。

kobject用struct kobject来描述。

kset是一些kobject的集合，这些kobject可以有相同的ktype，也可以不同。同时，kset自己也包含一个kobject。在sysfs中，kset也是对应这一个目录，但是目录下面包含着其他的kojbect。

每个kobject对象都内嵌有一个ktype，该结构定义了kobject在创建和删除时所采取的行为。

device和driver里面都有一个成员变量bus，表示它们归哪个总线管理；

bus里面则有两个链表，device链表和driver链表。

当有新的设备加入的时候，就会将它加入它对应的bus的device链表，然后在它的驱动链表中寻找是否有驱动driver和该device匹配成功，如果匹配成功设备就可以正常使用了，否则，不好意思继续等待。

当有新的驱动加入的时候，就会将它加入它对应的bus的driver链表，然后在它的设备链表中寻找是否有设备device和该driver匹配成功，如果成功设备就可以正常使用了

bus_add_device()

bus_probe_device

device_attach

__device_attach

理解Linux的IO模型之前，首先要了解一些基本概念，才能理解这些IO模型设计的依据

*** 作系统使用虚拟内存来映射物理内存，对于32位的 *** 作系统来说，虚拟地址空间为4G（2^32）。 *** 作系统的核心是内核，为了保护用户进程不能直接 *** 作内核，保证内核安全， *** 作系统将虚拟地址空间划分为内核空间和用户空间。内核可以访问全部的地址空间，拥有访问底层硬件设备的权限，普通的应用程序需要访问硬件设备必须通过 系统调用 来实现。

对于Linux系统来说，将虚拟内存的最高1G字节的空间作为内核空间仅供内核使用，低3G字节的空间供用户进程使用，称为用户空间。

又被称为标准I/O，大多数文件系统的默认I/O都是缓存I/O。在Linux系统的缓存I/O机制中， *** 作系统会将I/O的数据缓存在页缓存（内存）中，也就是数据先被拷贝到内核的缓冲区（内核地址空间），然后才会从内核缓冲区拷贝到应用程序的缓冲区（用户地址空间）。

这种方式很明显的缺点就是数据传输过程中需要再应用程序地址空间和内核空间进行多次数据拷贝 *** 作，这些 *** 作带来的CPU以及内存的开销是非常大的。

由于Linux系统采用的缓存I/O模式，对于一次I/O访问，以读 *** 作举例，数据先会被拷贝到内核缓冲区，然后才会从内核缓冲区拷贝到应用程序的缓存区，当一个read系统调用发生的时候，会经历两个阶段：

正是因为这两个状态，Linux系统才产生了多种不同的网络I/O模式的方案

Linux系统默认情况下所有socke都是blocking的，一个读 *** 作流程如下：

以UDP socket为例，当用户进程调用了recvfrom系统调用，如果数据还没准备好，应用进程被阻塞，内核直到数据到来且将数据从内核缓冲区拷贝到了应用进程缓冲区，然后向用户进程返回结果，用户进程才解除block状态，重新运行起来。

阻塞模行下只是阻塞了当前的应用进程，其他进程还可以执行，不消耗CPU时间，CPU的利用率较高。

Linux可以设置socket为非阻塞的，非阻塞模式下执行一个读 *** 作流程如下：

当用户进程发出recvfrom系统调用时，如果kernel中的数据还没准备好，recvfrom会立即返回一个error结果，不会阻塞用户进程，用户进程收到error时知道数据还没准备好，过一会再调用recvfrom，直到kernel中的数据准备好了，内核就立即将数据拷贝到用户内存然后返回ok，这个过程需要用户进程去轮询内核数据是否准备好。

非阻塞模型下由于要处理更多的系统调用，因此CPU利用率比较低。

应用进程使用sigaction系统调用，内核立即返回，等到kernel数据准备好时会给用户进程发送一个信号，告诉用户进程可以进行IO *** 作了，然后用户进程再调用IO系统调用如recvfrom，将数据从内核缓冲区拷贝到应用进程。流程如下：

相比于轮询的方式，不需要多次系统调用轮询，信号驱动IO的CPU利用率更高。

异步IO模型与其他模型最大的区别是，异步IO在系统调用返回的时候所有 *** 作都已经完成，应用进程既不需要等待数据准备，也不需要在数据到来后等待数据从内核缓冲区拷贝到用户缓冲区，流程如下：

在数据拷贝完成后，kernel会给用户进程发送一个信号告诉其read *** 作完成了。

是用select、poll等待数据，可以等待多个socket中的任一个变为可读，这一过程会被阻塞，当某个套接字数据到来时返回，之后再用recvfrom系统调用把数据从内核缓存区复制到用户进程，流程如下：

流程类似阻塞IO，甚至比阻塞IO更差，多使用了一个系统调用，但是IO多路复用最大的特点是让单个进程能同时处理多个IO事件的能力，又被称为事件驱动IO，相比于多线程模型，IO复用模型不需要线程的创建、切换、销毁，系统开销更小，适合高并发的场景。

select是IO多路复用模型的一种实现，当select函数返回后可以通过轮询fdset来找到就绪的socket。

优点是几乎所有平台都支持，缺点在于能够监听的fd数量有限，Linux系统上一般为1024，是写死在宏定义中的，要修改需要重新编译内核。而且每次都要把所有的fd在用户空间和内核空间拷贝，这个 *** 作是比较耗时的。

poll和select基本相同，不同的是poll没有最大fd数量限制（实际也会受到物理资源的限制，因为系统的fd数量是有限的），而且提供了更多的时间类型。

总结：select和poll都需要在返回后通过轮询的方式检查就绪的socket，事实上同时连的大量socket在一个时刻只有很少的处于就绪状态，因此随着监视的描述符数量的变多，其性能也会逐渐下降。

epoll是select和poll的改进版本，更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

epoll_create()用来创建一个epoll句柄。

epoll_ctl() 用于向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上，通过回调函数内核会将 I/O 准备好的描述符加入到一个就绪链表中管理。

epoll_wait() 可以从就绪链表中得到事件完成的描述符，因此进程不需要通过轮询来获得事件完成的描述符。

当epoll_wait检测到描述符IO事件发生并且通知给应用程序时，应用程序可以不立即处理该事件，下次调用epoll_wait还会再次通知该事件，支持block和nonblocking socket。

当epoll_wait检测到描述符IO事件发生并且通知给应用程序时，应用程序需要立即处理该事件，如果不立即处理，下次调用epoll_wait不会再次通知该事件。

ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用nonblocking socket，以避免由于一个文件句柄的阻塞读/阻塞写 *** 作把处理多个文件描述符的任务饿死。

【segmentfault】 Linux IO模式及 select、poll、epoll详解

【GitHub】 CyC2018/CS-Notes

---