linux驱动程序结构框架及工作原理分别是什么？

一、Linux device driver 的概念\x0d\x0a\x0d\x0a系统调用是 *** 作系统内核和应用程序之间的接口，设备驱动程序是 *** 作系统内核和机器硬件之间的接枣圆口。设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以象 *** 作普通文件一样对硬件设备进行 *** 作。设备驱动程序是内核的一部分，它完成以下的功能:\x0d\x0a\x0d\x0a1、对设早岩裤备初始化和释放；\x0d\x0a\x0d\x0a2、把数据从内核传送到硬件和从硬件读取数据；\x0d\x0a\x0d\x0a3、读取应用程序传送给设备文件的数据和回送应用程序请求的数据；\x0d\x0a\x0d\x0a4、检测和处理设备出现的错误。\x0d\x0a\x0d\x0a在Linux *** 作系统下有三类主要的设备文件类型，一是字符设备，二是块设备，三是网络设备。字符设备和块设备的主要区别是:在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了，块设备则不然，它利用一块系统内存作缓冲区，当用户进程对设备请求能满足用户的要求，就返回请求的数据，如果不能，就调用请求函数来进行实际的I/O *** 作。块设备是主要针对磁盘等慢速设备设计的，以免耗费过多的CPU时间来陆简等待。\x0d\x0a\x0d\x0a已经提到，用户进程是通过设备文件来与实际的硬件打交道。每个设备文件都都有其文件属性(c/b)，表示是字符设备还是块设备?另外每个文件都有两个设备号，第一个是主设备号，标识驱动程序，第二个是从设备号，标识使用同一个设备驱动程序的不同的硬件设备，比如有两个软盘，就可以用从设备号来区分他们。设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号一致，否则用户进程将无法访问到驱动程序。\x0d\x0a\x0d\x0a最后必须提到的是，在用户进程调用驱动程序时，系统进入核心态，这时不再是抢先式调度。也就是说，系统必须在你的驱动程序的子函数返回后才能进行其他的工作。如果你的驱动程序陷入死循环，不幸的是你只有重新启动机器了，然后就是漫长的fsck。\x0d\x0a\x0d\x0a二、实例剖析\x0d\x0a\x0d\x0a我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理。把下面的C代码输入机器，你就会获得一个真正的设备驱动程序。\x0d\x0a\x0d\x0a由于用户进程是通过设备文件同硬件打交道，对设备文件的 *** 作方式不外乎就是一些系统调用，如 open，read，write，close?， 注意，不是fopen， fread，但是如何把系统调用和驱动程序关联起来呢?这需要了解一个非常关键的数据结构：\x0d\x0a\x0d\x0aSTruct file_operatiONs {\x0d\x0a\x0d\x0aint (*seek) (struct inode * ，struct file *， off_t ，int)\x0d\x0a\x0d\x0aint (*read) (struct inode * ，struct file *， char ，int)\x0d\x0a\x0d\x0aint (*write) (struct inode * ，struct file *， off_t ，int)\x0d\x0a\x0d\x0aint (*readdir) (struct inode * ，struct file *， struct dirent * ，int)\x0d\x0a\x0d\x0aint (*select) (struct inode * ，struct file *， int ，select_table *)\x0d\x0a\x0d\x0aint (*ioctl) (struct inode * ，struct file *， unsined int ，unsigned long)\x0d\x0a\x0d\x0aint (*mmap) (struct inode * ，struct file *， struct vm_area_struct *)\x0d\x0a\x0d\x0aint (*open) (struct inode * ，struct file *)\x0d\x0a\x0d\x0aint (*release) (struct inode * ，struct file *)\x0d\x0a\x0d\x0aint (*fsync) (struct inode * ，struct file *)\x0d\x0a\x0d\x0aint (*fasync) (struct inode * ，struct file *，int)\x0d\x0a\x0d\x0aint (*check_media_change) (struct inode * ，struct file *)\x0d\x0a\x0d\x0aint (*revalidate) (dev_t dev)\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0a这个结构的每一个成员的名字都对应着一个系统调用。用户进程利用系统调用在对设备文件进行诸如read/write *** 作时，系统调用通过设备文件的主设备号找到相应的设备驱动程序，然后读取这个数据结构相应的函数指针，接着把控制权交给该函数。这是linux的设备驱动程序工作的基本原理。既然是这样，则编写设备驱动程序的主要工作就是编写子函数，并填充file_operations的各个域。\x0d\x0a\x0d\x0a下面就开始写子程序。\x0d\x0a\x0d\x0a#include 基本的类型定义\x0d\x0a\x0d\x0a#include 文件系统使用相关的头文件\x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0aunsigned int test_major = 0\x0d\x0a\x0d\x0astatic int read_test(struct inode *inode，struct file *file，char *buf，int count)\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aint left用户空间和内核空间\x0d\x0a\x0d\x0aif (verify_area(VERIFY_WRITE，buf，count) == -EFAULT )\x0d\x0a\x0d\x0areturn -EFAULT\x0d\x0a\x0d\x0afor(left = count left >0 left--)\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0a__put_user(1，buf，1)\x0d\x0a\x0d\x0abuf++\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0areturn count\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0a这个函数是为read调用准备的。当调用read时，read_test()被调用，它把用户的缓冲区全部写1。buf 是read调用的一个参数。它是用户进程空间的一个地址。但是在read_test被调用时，系统进入核心态。所以不能使用buf这个地址，必须用__put_user()，这是kernel提供的一个函数，用于向用户传送数据。另外还有很多类似功能的函数。请参考，在向用户空间拷贝数据之前，必须验证buf是否可用。这就用到函数verify_area。为了验证BUF是否可以用。\x0d\x0a\x0d\x0astatic int write_test(struct inode *inode，struct file *file，const char *buf，int count)\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0areturn count\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0astatic int open_test(struct inode *inode，struct file *file )\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aMOD_INC_USE_COUNT模块计数加以，表示当前内核有个设备加载内核当中去\x0d\x0a\x0d\x0areturn 0\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0astatic void release_test(struct inode *inode，struct file *file )\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aMOD_DEC_USE_COUNT\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0a这几个函数都是空 *** 作。实际调用发生时什么也不做，他们仅仅为下面的结构提供函数指针。\x0d\x0a\x0d\x0astruct file_operations test_fops = {?\x0d\x0a\x0d\x0aread_test，\x0d\x0a\x0d\x0awrite_test，\x0d\x0a\x0d\x0aopen_test，\x0d\x0a\x0d\x0arelease_test，\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0a设备驱动程序的主体可以说是写好了。现在要把驱动程序嵌入内核。驱动程序可以按照两种方式编译。一种是编译进kernel，另一种是编译成模块(modules)，如果编译进内核的话，会增加内核的大小，还要改动内核的源文件，而且不能动态的卸载，不利于调试，所以推荐使用模块方式。\x0d\x0a\x0d\x0aint init_module(void)\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aint result\x0d\x0a\x0d\x0aresult = register_chrdev(0， "test"， &test_fops)对设备 *** 作的整个接口\x0d\x0a\x0d\x0aif (result \x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0a#include \x0d\x0a\x0d\x0amain()\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aint testdev\x0d\x0a\x0d\x0aint i\x0d\x0a\x0d\x0achar buf[10]\x0d\x0a\x0d\x0atestdev = open("/dev/test"，O_RDWR)\x0d\x0a\x0d\x0aif ( testdev == -1 )\x0d\x0a\x0d\x0a{\x0d\x0a\x0d\x0aprintf("Cann't open file \n")\x0d\x0a\x0d\x0aexit(0)\x0d\x0a\x0d\x0a}\x0d\x0a\x0d\x0aread(testdev，buf，10)\x0d\x0a\x0d\x0afor (i = 0i 回答于 2022-11-18

原因如下：

1是此补丁已失效。

2是电脑上已装有包含此问题的更新补丁，则只能忽略了。

可以到到微软官网下载更新 ，碧握对应你 *** 作系统是32bit或64bit下载安装，安装完成后重启电脑。重启完成问题解决！

扩展资料：

Windows系统中两种基本驱动程序之一，它的特点是：

1、内核模式驱动程序将在执行其他应用程序代码（包括受保护的子系统代码）的非特权处理器模式中运行。除森圆非用户模式驱动程序调用 Win32 API，否则将无法获取对系统数据的访问权。

2、内核模式驱动程序将作为 *** 作系统的执行部分（即支持一个或多个受保护的子系统的基础 *** 作系统组件）运行。大多数设备驱动程序将在内核模式中运行。

内核模式驱动程序可执行某些受保护的 *** 作，并可访问用户模悔春庆式驱动程序无法访问的系统结构。但随着访问权的增加，调试难度和系统损害几率也随之增大。

参考资料：百度百科-内核模式驱动

前面写了一些SPI/I2C/RS-485之类的文章，有朋友留言希望能分享一些USB方面的梳理总结，今天就从系统标准层面先来梳理一下。看看有没有朋友喜欢。先从系统层面来梳理。个人学习，习惯于先从整体上摸个大概，然后再对感兴趣的细节逐渐深入。

USB是比较复杂的协议栈，如果发现文章中有错误，请帮忙指正。

注：本文主要参考USB2.0规范第4章，将标准中个人认为比较重要的一些点尽量条理清晰的总结出来。我感觉很多朋友可能对于阅读英文标准有点轻度抗拒，所以整理此文这也是一个起因，希望对朋友们有所帮助。

总线拓扑

说到总线拓扑，这张图大型握备家一定都见过：

USB标准上说USB总线拓扑是一种分层星形结构，这张拓扑图延申出来的一些要点：

所谓星型是针对Hub而言的，一个Hub下面可以挂Hub或者设备，最顶层就是USB主机控制器USB主机控制器一般都伴随有一个根集线器Root Hub。Hub级联最多5层总线上理论最大允许连接127个设备。Hub级联遵循向下兼容，USB2.0主机或者高速Hub可以连接USB1.1Hub。一个USB分层星型结构有且仅有一个USB主机控制器线缆最长不超过5米这个最大7层星形结构，代表的是一条USB总线，一个USB分层星型结构有且仅有一个USB主机控制器，但并不是说一台计算机就只有一个USB总线，比如我的计算机内部就是2个USB主控制器+Root Hub，从Windows设备管理器可以看到：

7层拓扑图中的第2层只画了一个Hub,并不意味真正的第2层就只能有一个Hub，但这个图无法显示出更为详细的总线连接关系，用USBTrace软件来看看：

第1条总线有4个端口，第2条总线的根集线器具有18个端口，其中8、9、10为计算机内部的USB设备占用了。我这台笔记本对外有两个USB接口，通过分别将U盘插入这两个端口，再利用USBTrace探测可以推断出这两个端口都属于第2条总线的Port

3以及Port 4：

那么Hub长什么样呢？比如下面是一个7口的USB Hub示意图，来源于USB2.0标准：

物理接口

电气概览

USB 通过四线电缆传输信号和电源。信令发生在每个点对点网段上的两条线上。

VBUS/GND：供电D+/D-：USB差分信号线。具有三种数据速率：

高速模式 high-speed：480 Mb/s，常缩写为HS模式全速模式 full-speed：12 Mb/s，常缩写为FS模式低速模式 low-speed：1.5 Mb/s，常缩写为LS模式至于数据编码模式，这里先不管它。

机卜毁械概览

机械部分主要皮段定义USB采用什么尺寸的接插件，线缆的颜色定义、线号。线缆的抗拉强度等。主要从以下几个方面去标准化：

主要连接器类型规范，主要分A、B系列。定义了公头、母头。

线缆规范。高速/全速电缆由信号双绞线、VBUS、GND 和整体屏蔽组成。当高速/全速电缆与低速设备一起使用时，电缆必须满足所有低速设备要求。低速设备可以不使用双绞线。双绞线可有效抵抗共模噪声。连接器机械尺寸及材料要求。

A/B系列插座规范A/B系列插头规范电缆尺寸材料规范，这里就不罗列了，知道在哪里查就可以了。电气、机械和环境合规性标准接地规范，屏蔽层一定要焊接在插头的外壳接地点。插座PCB尺寸规范。所以对于有绘制接插件需要的，可以参考6.9节的尺寸。Logo位置线芯颜色规范。USB Logo尺寸规范。协议概述

USB采用主从通讯模式，是一种轮询总线。所有数据传输都由主机控制器发起。这是USB标准中最难啃的部分，这里先不总结。

健壮设计

标准关于协议健壮性，又称鲁棒性，做了这几个方面的设计：

从信号完整性角度：使用差分驱动器、差分接收器和以及对信号线缆的屏蔽处理。差分收发策略主要在抵抗共模干扰方面效果显著，而屏蔽层则有两方面的作用：其一，有效降低USB线通过无线电波对外界干扰；其二、能有效隔断外界无线干扰对USB信号线、电源线的干扰。CRC报文校验。报文中数据如果出错，可以检测出来，可以做相应的处置。热插拔检测及对相应硬件设备的系统配置管理。这个设计有助于提升用户体验，用户随用随插，而无需关机插拔。利用对数据丢失或数据损坏超时检测实现通讯自恢复机制，以增强协议的健壮性。对流数据的进行流量控制以确保同步以及底层收发硬件缓冲区管理。数据管道和控制管道分离

---