Linux设备驱动程序学习（15）
-Linux设备模型（热插拔、mdev 与firmware）
热插拔
有2 个不同角度来看待热插拔：
从内核角度看，热插拔是在硬件、内核和内核驱动之间的交互。
从用户角度看，热插拔是内核和用户空间之间，通过调用用户空间程序（如hotplug、udev 和mdev）的交互。当需要通知用户内核发生了某种热插拔事件时，内核才调用这个用户空间程序。
现在的计算机系统，要求Linux 内核能够在硬件从系统中增删时，可靠稳定地运行。这就对设备驱动作
者增加了压力，因为在他们必须处理一个毫无征兆地突然出现或消失的设备。
热插拔工具
当用户向系统添加或删除设备时，内核会产生一个热插拔事件，并在/proc/sys/kernel/hotplug文件里查找处理设备连接的用户空间程序。这个用户空间程序主要有
hotplug:这个程序是一个典型的bash 脚本，只传递执行权给一系列位于/etc/hot-plug.d/ 目录树的程序。hotplug 脚本搜索所有的有 .hotplug 后缀的可能对这个事件进行处理的程序并调用它们, 并传递给它们许多不同的已经被内核设置的环境变量。(基本已被淘汰，具体内容请参阅《LDD3》)
udev ：用于linux2.6.13或更高版本的内核上，为用户空间提供使用固定设备名的动态/dev目录的解
决方案。它通过在sysfs 的/class/ 和/block/ 目录树中查找一个称为dev 的文件，以确定所创建的
设备节点文件的主次设备号。所以要使用udev，驱动必须为设备在sysfs中创建类接口及其dev属性文件，方法和sculld模块中创建dev属性相同。udev的资料网上十分丰富，我就不在这废话了，给出以
下链接有兴趣的自己研究：
mdev：一个简化版的udev，是busybox所带的程序，十分适合嵌入式系统。
因为hotplug现在也在被慢慢地淘汰，udev不再依赖hotplug了，所以这里不再介绍；
udev较mdev复杂，不太适合嵌入式使用。（本人也有做udev的实验，交叉编译是通过了，但是使用上有问题，没有实现其功能。也许是我的文件系统没做好，以后有时间再研究和写记录。有成功高人的通知一声，交流一下经验。^_^谢谢！）；
mdev简单易用，比较适合嵌入式系统，实验成功。以下详细介绍mdev的使用。
mdev
在一开始建立根文件系统时，我根据WeiBing 的博客上《UDEV on embeded Linux-2.6.19.2》（地址：https://www.doczj.com/doc/59929050.html,/logs/4485453.html）这篇文章的提示，开始使用mdev，但是当时只是启动时mdev -s 一下，并没有深究。现在在学习了Linux设备模型之后，对于Linux中/dev目录的动态管理有了更深的认识，并认真的看了一下busybox中的mdev.txt文档并翻译了一下，做成了PDF（下载地址：https://www.doczj.com/doc/59929050.html,/blog/upfile2/080111091002.pdf），在看下面的内容时请先看看这篇文档。
先声明一个要点：要实现设备节点文件的自动、动态的增删，必须在你自己的驱动源码中实现类接口，并在类设备的目录中添加包含设备号的名为“dev”的属性文件。
mdev原理及bug
要使用mdev，适当知道一下原理是必不可少的（能完整地研究mdev源码是最好的）。说实话起初我并没有想看mdev的源码，是在使用时发现了问题后才去研究了一下mdev的源码。现在简单介绍一下mdev 的原理：
执行mdev -s：以…-s?为参数调用位于/sbin目录写的mdev（其实是个链接，作用是传递参数给/bin
目录下的busybox程序并调用它），mdev扫描/sys/class 和/sys/block 中所有的类设备目录，如果在目录中含有名为“dev”的文件，且文件中包含的是设备号，则mdev就利用这些信息为这个设备在/dev 下创建设备节点文件。一般只在启动时才执行一次“mdev -s”。
热插拔事件：由于启动时运行了命令：echo /sbin/mdev > /proc/sys/kernel/hotplug ，那么当有热插拔事件产生时，内核就会调用位于/sbin目录的mdev。这时mdev通过环境变量中的 ACTION 和DEVPATH，来确定此次热插拔事件的动作以及影响了/sys中的那个目录。接着会看看这个目录中是否有“dev”的属性文件，如果有就利用这些信息为这个设备在/dev 下创建设备节点文件。
mdev使用
mdev的使用在busybox中的mdev.txt文档已经将得很详细了。但作为例子，我简单讲讲我的使用过程：
（1）在编译时加上对mdev的支持（我是使用的是busybox1.9.0）：
Linux System Utilities --->
[*] mdev
[*] Support /etc/mdev.conf
[*] Support command execution at device addition/removal
（2）在启动时加上使用mdev的命令：
我在自己创建的根文件系统（nfs）中的/linuxrc文件中添加了如下指令：
注意：是
/bin/mdev >/proc/sys/kernel/hotplug。busybox的文档有错！！
（3）在你的驱动中加上对类设备接口的支持，并在类设备目录下添加包含设备号的名为“dev”的属性文件。
（4）至于/etc/mdev.conf文件，可有可无，不影响使用，只是添加了些功能。
为了实验我在/etc创建了mdev.conf文件并输入了：
具体的实验源码和现象在文章后面有。
firmware
硬件市场的激烈竞争, 使得制造商连一点用于设备控制固件的EEPROM 的成本都不愿意花费。因此固件一般发布在和硬件配套的驱动包中，由操作系统（其实是驱动程序）负责传送固件到设备。
内核固件接口
获取固件的正确方法是当需要时从用户空间获取它。一定不要试图从内核空间直接打开包含固件的文件，那是一个易出错的操作, 因为它把策略(以文件名的形式)包含进了内核。正确的方法是使用固件接口:
注意：要使用firmware，必须要在配置内核时选上：
Device Drivers --->
Generic Driver Options --->
<*> Userspace firmware loading support
否则会出现: Unknown symbol release_firmware 和: Unknown symbol request_firmware 的错误。
固件接口工作原理
固件子系统使用sysfs 和热插拔机制工作。当调用request_firmware时, 函数将在
/sys/class/firmware 下创建一个以设备名为目录名的新目录，其中包含3 个属性:
loading：这个属性应当被加载固件的用户空间进程设置为1。当加载完毕, 它将被设为0。被设为-1 时，将中止固件加载。
data：一个用来接收固件数据的二进制属性。在设置loading 为1后, 用户空间进程将固件写入这个属
性。
device：一个链接到/sys/devices 下相关入口项的符号链接。
一旦创建了sysfs 入口项, 内核将为设备产生一个热插拔事件，并传递包括变量FIRMWARE 的环境变量给处理热插拔的用户空间程序。FIRMWARE 被设置为提供给request_firmware 的固件文件名。
用户空间程序定位固件文件, 并将其拷贝到内核提供的二进制属性；若无法定位文件, 用户空间程序设置loading 属性为-1。
若固件请求在10 秒内没有被服务, 内核就放弃并返回一个失败状态给驱动。超时周期可通过sysfs 属性/sys/class/firmware/timeout 属性改变。
request_firmware 接口允许使用驱动发布设备固件。当正确地集成进热插拔机制后, 固件加载子系统允许设备不受干扰地工作。显然这是处理问题的最好方法，但固件受版权保护，小心违反版权法。
ARM9开发板实验
实验源码：
https://www.doczj.com/doc/59929050.html,/blog/upfile2/080114113255. gz
第31卷 第2期 2008年4月 电子器件 Ch in es e Jo u rnal Of Electro n Devi ces Vol.31 No.2Apr.2008 Design and Implementation of Audio Driver for Embedded Linux System YU Yue,YA O G uo -liang * (N ational A S I C S ystem Eng ine ering Center ,S outhe ast Unive rsity ,N anj ing 210096,China) Abstract:This paper intro duces the fundam ental principle and architecture of the audio system w hich con -sists of the CODEC UCB1400and the 805puls,and describes the design of audio dev ice dr iv er based on Audio Codec .97for Embedded Linux System.The paper focuses o n the implementatio n of the DM A trans -port and ioctl interface.T he audio dr iv e is running w ell in actual Embedded Linux system equipments.Key words:805plus;embedded Linux;Audio A C .97driver;DM A;ioctl interface EEACC :1130B 嵌入式Linux 系统中音频驱动的设计与实现 虞 跃,姚国良 * (东南大学国家专用集成电路系统工程中心,南京210096) 收稿日期:2007-07-09 作者简介:虞 跃(1982-),男,东南大学电子工程系国家专用集成电路工程技术研究中心硕士研究生,研究方向为嵌入式系统设计; 姚国良(1979-),男,东南大学电子工程系博士研究生,yuyueo@https://www.doczj.com/doc/59929050.html,. 摘 要:介绍了由805puls 处理器和U CB1400编解码芯片构成的音频系统体系结构及工作原理,接着阐述了嵌入式Linux 操作系统下基于A C .97协议标准的音频设备驱动程序的设计与实现。其中着重讲述了采用循环缓冲区进行音频数据的DM A 传输流程以及ioctl 接口的实现。此设计方案已在嵌入式L inux 系统中得到使用,运行效果良好。 关键词:805plus;嵌入式L inux ;AC .97音频驱动;DM A;ioctl 接口中图分类号:TP391 文献标识码:A 文章编号:1005-9490(2008)02-0709-03 嵌入式音频系统广泛应用于GPS 自动导航、PDA,3G 手机等移动信息终端,具备播放、录音功能的音频系统的应用使得移动信息终端上视听娱乐IP 电话、音频录制等成为可能,并推动了移动信息终端设备的发展。 在软件上,嵌入式操作系统的新兴力量Linux 的开源性,内核可定制等优点吸引了许多的开发者与开发商。它是个和U nix 相似、以核心为基础的、完全内存保护、多任务多进程的操作系统。支持广泛的计算机硬件,包括X86,A lpha,Sparc,M IPS,PPC,ARM ,NEC,MOT OROLA 等现有的大部分芯片[1]。 本文针对805puls 微处理器选用Philips 公司的编解码芯片(CODEC)U CB1400,构建了基于Au -dio Codec .97(AC .97)标准的音频系统。并介绍了该音频系统在Linux 操作系统2.4.19内核下驱动 程序的实现技术。 1 音频系统构架 1.1 微处理器805plus 805plus 是东南大学ASIC 系统工程技术研究中心和北京大学微处理器研究开发中心共同设计和开发的32bit 嵌入式微处理器,是采用H ar vard 结构的RISC 处理器。内部采用五级流水线结构,兼容16bit 和32bit 的指令系统805plus 嵌入式微处理器集成了存储接口EMI,时钟和功耗管理PM C,中断控制器INTC,通用定时器T IM ER,脉宽调制器PWM,实时时钟RT C,通用串口UA RT,LCD 控制器LCDC,AC .97控制器,同步外设接口SPI 。1.2 AC .97协议标准[2] AC'97协议标准是一套关于A C'97数字音频处理(AC'97Digital Controller)、AC '97数字串口(AC
CAN总线在嵌入式Linux下驱动程序的实现 时间：2009-11-05 09:41:22 来源：微计算机信息作者：黄捷峰蔡启仲郭毅锋田小刚 1 引言 基于嵌入式系统设计的工业控制装置，在工业控制现场受到各种干扰，如电磁、粉尘、天气等对系统的正常运行造成很大的影响。在工业控制现场各个设备之间要经常交换、传输数据，需要一种抗干扰性强、稳定、传输速率快的现场总线进行通信。文章采用CAN总线，基于嵌入式系统32位的S3C44B0X微处理器，通过其SPI接口，MCP2510 CAN控制器扩展CAN总线；将嵌入式操作系统嵌入到S3C44B0X微处理器中，能实现多任务、友好图形用户界面；针对S3C44B0X微处理器没有内存管理单元MMU，采用uClinux嵌入式操作系统。这样在嵌入式系统中扩展CAN设备关键技术就是CAN设备在嵌入式操作系统下驱动程序的实现。文章重点解决了CAN总线在嵌入式操作系统下驱动程序实现的问题。对于用户来说，CAN设备在嵌入式操作系统驱动的实现为用户屏蔽了硬件的细节，用户不用关心硬件就可以编出自己的用户程序。实验结果表明驱动程序的正确性，能提高整个系统的抗干扰能力，稳定性好，最大传输速率达到1Mb/s；硬件的错误检定特性也增强了CAN的抗电磁干扰能力。 2 系统硬件设计 系统采用S3C44B0X微处理器,需要扩展CAN控制器。常用的CAN控制器有SJA1000和MCP2510,这两种芯片都支持CAN2.0B标准。SJA1000采用的总线是地址线和数据线复用的方式，但是嵌入式处理器外部总线大多是地址线和数据线分开的结构，这样每次对SJA1000操作时需要先后写入地址和数据2次数据，而且SJA1000使用5V逻辑电平。所以应用MCP2510控制器进行扩展，收发器采用82C250。MCP2510控制器特点：1.支持标准格式和扩展格式的CAN数据帧结构（CAN2.0B）；2.0～8字节的有效数据长度，支持远程帧；3.最大1Mb/s的可编程波特率；4.2个支持过滤器的接受缓冲区，3个发送缓冲区； 5.SPI高速串行总线，最大5MHz； 6.3～5.5V宽电压范围供电。MCP2510工作电压为3.3V，能够直接与S3C44B0X微处理器I/O口相连。为了进一步提高系统抗干扰性，可在CAN控制器和收发器之间加一个光隔6N137。其结构原理框图如图1： 图1.S3C44B0X扩展CAN结构框图图2.字符设备注册表 3 CAN设备驱动程序的设计 Linux把设备看成特殊的文件进行管理，添加一种设备，首先要注册该设备，增加它的驱动。设备驱动程序是操作系统内核与设备硬件之间的接口，并为应用程序屏蔽了硬件细节。在linux中用户进程不能直接对物理设备进行操作，必须通过系统调用向内核提出请求，
1、字符型驱动设备你是怎么创建设备文件的，就是/dev/下面的设备文件，供上层应用程序打开使用的文件？ 答：mknod命令结合设备的主设备号和次设备号，可创建一个设备文件。 评：这只是其中一种方式，也叫手动创建设备文件。还有UDEV/MDEV自动创建设备文件的方式，UDEV/MDEV是运行在用户态的程序，可以动态管理设备文件，包括创建和删除设备文件，运行在用户态意味着系统要运行之后。那么在系统启动期间还有devfs创建了设备文件。一共有三种方式可以创建设备文件。 2、写一个中断服务需要注意哪些？如果中断产生之后要做比较多的事情你是怎么做的？答：中断处理例程应该尽量短，把能放在后半段(tasklet，等待队列等)的任务尽量放在后半段。 评：写一个中断服务程序要注意快进快出，在中断服务程序里面尽量快速采集信息，包括硬件信息，然后推出中断，要做其它事情可以使用工作队列或者tasklet方式。也就是中断上半部和下半部。 第二：中断服务程序中不能有阻塞操作。为什么？大家可以讨论。 第三：中断服务程序注意返回值，要用操作系统定义的宏做为返回值，而不是自己定义的OK，FAIL之类的。 3、自旋锁和信号量在互斥使用时需要注意哪些？在中断服务程序里面的互斥是使用自旋锁还是信号量？还是两者都能用？为什么？ 答：使用自旋锁的进程不能睡眠，使用信号量的进程可以睡眠。中断服务例程中的互斥使用的是自旋锁，原因是在中断处理例程中，硬中断是关闭的，这样会丢失可能到来的中断。 4、原子操作你怎么理解？为了实现一个互斥，自己定义一个变量作为标记来作为一个资源只有一个使用者行不行？ 答：原子操作指的是无法被打断的操作。我没懂第二句是什么意思，自己定义一个变量怎么可能标记资源的使用情况？其他进程又看不见这个变量 评：第二句话的意思是： 定义一个变量,比如 int flag =0; if(flag == 0) { flag = 1; 操作临界区； flag = 0; }这样可否？
Linux设备驱动模型之platform总线深入浅出 在Linux2.6以后的设备驱动模型中，需关心总线，设备和驱动这三种实体，总线将设备和驱动绑定。在系统每注册一个设备的时候，会寻找与之匹配的驱动；相反，在系统每注册一个驱动的时候，会寻找与之匹配的设备，而匹配由总线完成。 对于依附在USB、PCI、I2C、SPI等物理总线来这些都不是问题。但是在嵌入式系统里面，在Soc系统中集成的独立外设控制器，挂接在Soc内存空间的外设等却不依附在此类总线。基于这一背景，Linux发明了一种总线，称为platform。相对于USB、PCI、I2C、SPI等物理总线来说，platform总线是一种虚拟、抽象出来的总线，实际中并不存在这样的总线。 platform总线相关代码：driver\base\platform.c 文件相关结构体定义：include\linux\platform_device.h 文件中 platform总线管理下最重要的两个结构体是platform_device和platform_driver 分别表示设备和驱动在Linux中的定义如下一：platform_driver //include\linux\platform_device.h struct platform_driver { int (*probe)(struct platform_device *); //探测函数，在注册平台设备时被调用int (*remove)(struct platform_device *); //删除函数，在注销平台设备时被调用void (*shutdown)(struct platform_device *); int (*suspend)(struct platform_device *, pm_message_t state); //挂起函数，在关机被调用int (*suspend_late)(struct platform_device *, pm_message_t state); int (*resume_early)(struct platform_device *); int (*resume)(struct platform_device *);//恢复函数，在开机时被调用struct device_driver driver;//设备驱动结构}; 1 2 3 4 5 6 7 8
Linux 内核文档翻译- driver-model/bus.txt Bus Types 总线类型 Definition 定义 ~~~~~~~~~~ See the kerneldoc for the struct bus_type. intbus_register(struct bus_type * bus); Declaration 声明 ~~~~~~~~~~~ Each bus type in the kernel (PCI, USB, etc) should declare one static object of this type. They must initialize the name field, and may optionally initialize the match callback. 内核中每个总线类型（PCI、USB 等等）都应该声明一个此类型的静态对象。它们必须初始化该对象的name 字段，然后可选的初始化match 回调函数。 structbus_typepci_bus_type = { .name = "pci", .match = pci_bus_match, }; The structure should be exported to drivers in a header file: 这个结构体应该在头文件中向驱动程序导出： extern struct bus_typepci_bus_type; Registration 注册 ~~~~~~~~~~~~ When a bus driver is initialized, it calls bus_register. This initializes the rest of the fields in the bus object and inserts it into a global list of bus types. Once the bus object is registered, the fields in it are usable by the bus driver. 当初始化一个总线驱动时，将会调用bus_register。这时这个总线对象剩下的字段将被初始化，然后这个对象会被插入到总线类型的一个全局列表里去。一旦完成一个总线对象的注册，那么对于总线驱动来说它里面的字段就已经可用了。
第一节基本概念 在设备模型里面，所有的东西都是kobject，这也是linux建立设备设计模型的目的（对比2.4之前），实现了统一的实体；我们理解上，却可以分为两个层次，一个是kobject，一个是管理kobject的kobject（可以把它叫做kset虽然有点绕，但是没有办法了，毕竟就像那个“世界上先有鸡还是先有蛋的哲学问题一下”）； kobject结构
1）前面两个顾名思义，就是name了，为什么会有两个呢？k_name就是指向name的，如何知道呢，呵呵，看一下代码 2）kref就是一个内核的原子计数结构，因为涉及内核的操作基本都需要是原子性的，为了大家的方便，kobject就把它包括进来了，所以大家就不必要各自定义自己的计数了（一般情况下：），poll也是类似，把等待队列包括进来； 3）entry 这个名字比较让人误解，其实看它的类型知道是list成员，它就是加入到kset的list 的那个零部件； 4）ktpye 要理解这个成员就稍微麻烦些了，先看一下定义 Default_attrs就是一种比较简单的设置属性文件的方法，它其实跟我们自己调用sysfs_create_file没有什么区别，呵呵，看一下代码就知道了，所以大家基本上可以把它忽略掉：），调用关系为kobject_add->create_dir->populate_dir 把一个忽略掉，剩下的两个就比较重要了；每个对象一般都有多个属性，用面向对象的角度来看，我们可以把对属性的操作抽象为show和store这一对方法，那么多个属性就会有多对show和store的方法；那么，为了实现对这些方法的统一调用，就利用ktype中的sysfs_ops 实现了多态；这样一来，对于sysfs中的普通文件读写操作都是由kobject->ktype->sysfs_ops
嵌入式linux android驱动工程师面试题总汇 1.嵌入式系统中断服务子程序(ISR)收藏中断是嵌入式系统中重要的组成部分，这导致了很多编译开发商提供一种扩展—让标准C支持中断。具代表事实是，产生了一个新的关键字__interrupt。下面的代码就使用了__interrupt关键字去定义了一个中断服务子程序(ISR)，请评论一下这段代码的。 2.C语言中对位的操作，比如对a的第三位清0，第四位置1.本来应该会的，一犯晕写反了，以后注意！ #define BIT3 (1<<3) #define BIT4 (1<<4) a &= ~BIT3;a |= BIT4; 3.考到volatile含义并举例： 理解出错，举了很具体的例子，连程序都搬上去了，有些理解不深的没举出来…… volatile表示这个变量会被意想不到的改变，每次用他的时候都会小心的重新读取一遍，不适用寄存器保存的副本。 volatile表示直接存取原始地址 例： 并行设备的硬件寄存器（状态寄存器） 在多线程运行的时候共享变量也要时时更新 一个中断服务子程序中访问到的的非自动变量（不太清楚，正在查找资料ing……） 4.要求设置一绝对地址为0x67a9的整型变量的值为0xaa66
当时我的写法： #define AA *（volatile unsigned long *）0xaa66AA = 0x67a9; 答案： int *ptr =（int *）0xaa66； *ptr = 0x67a9； 我感觉自己写的应该不算错吧（自我感觉，还请达人指正），我写的适合裸机下用，当做寄存器用，而答案就是适合在操作系统下的写法。 1. linux内核里面，内存申请有哪几个函数，各自的区别？ 2. IRQ和FIQ有什么区别，在CPU里面是是怎么做的？ 3. int *a; char *b; a 和b本身是什么类型？ a、b里面本身存放的只是一个地址，难道是这两个地址有不同么？ 4.xx的上半部分和下半部分的问题： 讲下分成上半部分和下半部分的原因，为何要分？讲下如何实现？ 5.内核函数mmap的实现原理，机制？ 6.驱动里面为什么要有并发、互斥的控制？如何实现？讲个例子？ 7. spinlock自旋锁是如何实现的？ 8.任务调度的机制？ 【二、本人碰到】
对一个具有四个按键的按键驱动的分析 源代码： /*Headers-------------------------------------------------*/ #include
Linux设备驱动程序学习（15） -Linux设备模型（热插拔、mdev 与firmware） 热插拔 有2 个不同角度来看待热插拔： 从内核角度看，热插拔是在硬件、内核和内核驱动之间的交互。 从用户角度看，热插拔是内核和用户空间之间，通过调用用户空间程序（如hotplug、udev 和mdev）的交互。当需要通知用户内核发生了某种热插拔事件时，内核才调用这个用户空间程序。 现在的计算机系统，要求Linux 内核能够在硬件从系统中增删时，可靠稳定地运行。这就对设备驱动作 者增加了压力，因为在他们必须处理一个毫无征兆地突然出现或消失的设备。 热插拔工具 当用户向系统添加或删除设备时，内核会产生一个热插拔事件，并在/proc/sys/kernel/hotplug文件里查找处理设备连接的用户空间程序。这个用户空间程序主要有 hotplug:这个程序是一个典型的bash 脚本，只传递执行权给一系列位于/etc/hot-plug.d/ 目录树的程序。hotplug 脚本搜索所有的有 .hotplug 后缀的可能对这个事件进行处理的程序并调用它们, 并传递给它们许多不同的已经被内核设置的环境变量。(基本已被淘汰，具体内容请参阅《LDD3》) udev ：用于linux2.6.13或更高版本的内核上，为用户空间提供使用固定设备名的动态/dev目录的解 决方案。它通过在sysfs 的/class/ 和/block/ 目录树中查找一个称为dev 的文件，以确定所创建的 设备节点文件的主次设备号。所以要使用udev，驱动必须为设备在sysfs中创建类接口及其dev属性文件，方法和sculld模块中创建dev属性相同。udev的资料网上十分丰富，我就不在这废话了，给出以 下链接有兴趣的自己研究：
第一章Linux设备驱动程序简介 Linux Kernel 系统架构图 一、驱动程序的特点 ?是应用和硬件设备之间的一个软件层。 ?这个软件层一般在内核中实现 ?设备驱动程序的作用在于提供机制，而不是提供策略，编写访问硬件的内核代码时不要给用户强加任何策略 o机制：驱动程序能实现什么功能。 o策略：用户如何使用这些功能。 二、设备驱动分类和内核模块 ?设备驱动类型。Linux 系统将设备驱动分成三种类型 o字符设备 o块设备 o网络设备 ?内核模块：内核模块是内核提供的一种可以动态加载功能单元来扩展内核功能的机制，类似于软件中的插件机制。这种功能单元叫内核模块。 ?通常为每个驱动创建一个不同的模块，而不在一个模块中实现多个设备驱动，从而实现良好的伸缩性和扩展性。 三、字符设备 ?字符设备是个能够象字节流<比如文件）一样访问的设备，由字符设备驱动程序来实现这种特性。通过/dev下的字符设备文件来访问。字符设备驱动程序通常至少需要实现 open、close、read 和 write 等系统调用 所对应的对该硬件进行操作的功能函数。 ?应用程序调用system call<系统调用），例如：read、write，将会导致操作系统执行上层功能组件的代码，这些代码会处理内核的一些内部 事务，为操作硬件做好准备，然后就会调用驱动程序中实现的对硬件进 行物理操作的函数，从而完成对硬件的驱动，然后返回操作系统上层功 能组件的代码，做好内核内部的善后事务，最后返回应用程序。 ?由于应用程序必须使用/dev目录下的设备文件<参见open调用的第1个参数），所以该设备文件必须事先创建。谁创建设备文件呢？ ?大多数字符设备是个只能顺序访问的数据通道，不能前后移动访问指针，这点和文件不同。比如串口驱动，只能顺序的读写设备。然而，也 存在和数据区或者文件特性类似的字符设备，访问它们时可前后移动访
嵌入式Linux下3G模块的驱动和应用 1、开发资源 1.1、硬件资源： ZTE-mf637u（中国联通） ZTE-mu351（中国移动） 1.2、软件资源： 1.2.1、usb-modeswitch-1.1.3 libusb-0.1.12.tar.gz usb-modeswitch-1.1.3.tar.bz2 1.2.2、ppp-2.4.4 libpcap-0.9.8.tar.gz ppp-2.4.4.tar.gz 1.2.3、wvdial 1.2.3.1、wvdial-1.54.0(arm-linux-gcc 3.4.1) zlib-1.2.5.tar.bz2 openssl-0.9.7g.tar.gz openssl-0.9.7g-fix_manpages-1.patch wvstreams-4.0.1.tar.bz2
wvstreams-4.0.1-tcl84-1.patch wvdial-1.54.0.tar.gz 1.2.3.2、wvdial_1.60.4(arm-linux-gcc 4.2.2) zlib-1.2.5.tar.bz2 openssl-0.9.8n.tar.gz openssl-0.9.8n-fix_manpages-1.patch wvstreams-4.6.1.tar.gz wvdial_1.60.4.tar.gz 2、Linux开发环境 2.1、主机环境 2.1.1、主机linux系统 Fedora Core 6 2.1.2、主机编译环境 2.1.2.1、gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile
文库资料?2017 Guangzhou ZHIYUAN Electronics Stock Co., Ltd. 如何实现Linux 设备驱动模型 设备驱动模型，对系统的所有设备和驱动进行了抽象，形成了复杂的设备树型结构，采用面向对象的方法，抽象出了device 设备、driver 驱动、bus 总线和class 类等概念，所有已经注册的设备和驱动都挂在总线上，总线来完成设备和驱动之间的匹配。总线、设备、驱动以及类之间的关系错综复杂，在Linux 内核中通过kobject 、kset 和subsys 来进行管理，驱动编写可以忽略这些管理机制的具体实现。 设备驱动模型的内部结构还在不停的发生改变，如device 、driver 、bus 等数据结构在不同版本都有差异，但是基于设备驱动模型编程的结构基本还是统一的。 Linux 设备驱动模型是Linux 驱动编程的高级内容，这一节只对device 、driver 等这些基本概念作介绍，便于阅读和理解内核中的代码。实际上，具体驱动也不会孤立的使用这些概念，这些概念都融合在更高层的驱动子系统中。对于大多数读者可以忽略这一节内容。 1.1.1 设备 在Linux 设备驱动模型中，底层用device 结构来描述所管理的设备。device 结构在文件
Linux设备模型：基本概念 1. 前言 在“Linux内核的整体架构”中，蜗蜗有提到，由于Linux支持世界上几乎所有的、不同功能的硬件设备（这是Linux的优点），导致Linux内核中有一半的代码是设备驱动，而且随着硬件的快速升级换代，设备驱动的代码量也在快速增长。个人意见，这种现象打破了“简洁就是美”的理念，是丑陋的。它导致Linux内核看上去非常臃肿、杂乱、不易维护。但蜗蜗也知道，这不是Linux的错，Linux是一个宏内核，它必须面对设备的多样性，并实现对应的驱动。 为了降低设备多样性带来的Linux驱动开发的复杂度，以及设备热拔插处理、电源管理等，Linux内核提出了设备模型（也称作Driver Model）的概念。设备模型将硬件设备归纳、分类，然后抽象出一套标准的数据结构和接口。驱动的开发，就简化为对内核所规定的数据结构的填充和实现。 本文将会从设备模型的基本概念开始，通过分析内核相应的代码，一步一步解析Linux设备模型的实现及使用方法。 2. Linux设备模型的基本概念 2.1 Bus, Class, Device和Device Driver的概念 下图是嵌入式系统常见的硬件拓扑的一个示例： 硬件拓扑描述Linux设备模型中四个重要概念中三个：Bus，Class和Device（第四个为Device Driver，后面会说）。 Bus（总线）：Linux认为（可以参考include/linux/device.h中struct bus_type的注释），总线是CPU和一个或多个设备之间信息交互的通道。而为了方便设备模型的抽象，所有的设备都应连接到总线上（无论是CPU内部总线、虚拟的总线还是“platform Bus”）。 Class（分类）：在Linux设备模型中，Class的概念非常类似面向对象程序设计中的Class （类），它主要是集合具有相似功能或属性的设备，这样就可以抽象出一套可以在多个设
linux内核部件分析（九）——设备驱动模型之device 前面我们分析了device、driver、bus三种类型，主要是三者的注册与注销，在sysfs中的目录与属性文件创建等内容。本节就来详细分析下，在设备注册到总线上时，总线是如何为其寻找对应的驱动的；在驱动注册到总线上时，总线又是如何为其寻找对应的设备的。 本节的实现代码集中在drivers/base/bus.c和 drivers/base/dd.c中。 先来回忆下，在device_register()->device_add()中，先是调用bus_add_device()添加device与bus间的联系，并添加bus 为device定义的属性，然后会调用bus_probe_device()。bus_probe_device()会试图为已挂在总线上的该设备寻找对应的驱动。我们的故事就从这里开始。 [cpp] view plaincopyprint?/** * bus_probe_device - probe drivers for a new device * @dev: device to probe * * - Automatically probe for a driver if the bus allows it. */ void bus_probe_device(struct device *dev) { struct bus_type *bus = dev->bus; int ret; if (bus && bus->p->drivers_autoprobe) { ret = device_attach(dev); WARN_ON(ret < 0); } } bus_probe_device()为总
LINUX设备模型 https://www.doczj.com/doc/59929050.html,/blog/static/6044209320094159558397/看了一段时间的驱动编程，从LDD3的hello wrod到后来的字符设备以至于更加复杂的驱动，越看越是觉得对linux驱动的结构不清楚，越看越是迷糊。于是就停下脚步搜索一下资料理一下头绪： 以下四个方面来总结一些内容： 1.底层数据结构：kobject,kset. 2.linux设备模型层次关系：bus_type,device,device_driver. 3.集成：PC I设备驱动模型实例及设备，设备驱动注册源码的简单分析. 4.面向对象的思想在linux设备模型中的应用分析. 一、底层数据结构：kobject,kset 先说说模型的意义: 总体来说是为了系统地管理所有设备。 在具体实现方面分两个层次： 一是底层数据结构来实现基本对象及其层次关系：kobjects和ksets。 二是基于这两个底层数据结构上实现的设备模型：总线，设备，驱动。 kobject 结合面向对象的思维。这个kobject属于最基础的结构，也就是最高抽象层(有点像java中的Cobject类)。任何一个设备模型如总线，设备，驱动都属于一个kobject 。在实现上这种派生关系就是在结构体中包含一个kobject的变量。 这个在层次上处理最顶层的kobject结构提供了所有模型需要的最基本的功能： 1 引用计数用于内核维护其存在与消亡 2 sysfs表示每个sys/下的对象对应着一个kobject。 3 热拔插事件处理。处理设备的热拔插事件。 Kobjects 在内核中对应有一套申请，初始化，添加，注册，计数操作，释放等函数 struct kobject { const char * k_name; 名 char name[KOBJ_NAME_LEN]; struct kref kref; 计数 struct list_head entry; 用于连接到同类kobjects的链表 struct kobject * parent; 用于实现层次，指向其父对象。 struct kset * kset; 用于实现层次，所属的集合 struct kobj_type * ktype; 指向对象的类型。 struct dentry * dentry; 指示在sysfs 中的目录项 wait_queue_head_t poll; }; (linux 2.6.18)
一：前言 Linux设备模型是一个极其复杂的结构体系，在编写驱动程序的时候，通常不会用到这方面的东西，但是。理解这部份内容，对于我们理解linux设备驱动的结构是大有裨益的。我们不但可以在编写程序程序的时候知其然，亦知其所以然。又可以学习到一种极其精致的架构设计方法。由于之前已经详细分析了sysfs文件系统。所以本节的讨论主要集中在设备模型的底层实现上。上层的接口，如pci.,usb ,网络设备都可以看成是底层的封装。 二：kobject ,kset和ktype Kobject,kset,kypte这三个结构是设备模型中的下层架构。模型中的每一个元素都对应一个kobject.kset和ktype可以看成是kobject在层次结构与属性结构方面的扩充。将三者之间的关系用图的方示描述如下： 如上图所示：我们知道。在sysfs中每一个目录都对应一个kobject.这些kobject都有自己的parent。在没有指定parent的情况下，都会指向它所属的kset->object。其次，kset也内嵌了kobject.这个kobject又可以指它上一级的parent。就这样。构成了一个空间上面的层次关系。 其实，每个对象都有属性。例如，电源管理，执插拨事性管理等等。因为大部份的同类设备都有相同的属性，因此将这个属性隔离开来，存放在ktype中。这样就可以灵活的管理了.记得在分析sysfs 的时候。对于sysfs中的普通文件读写操作都是由kobject->ktype->sysfs_ops来完成的. 经过上面的分析，我们大概了解了kobject.kset与ktype的大概架设与相互之间的关系。下面我们从linux源代码中的分析来详细研究他们的操作。 三:kobject,kset和ktype的操作 为了说明kobject的操作，先写一个测试模块，代码如下： #include
sysfs是kobject的表达，所以这里翻译了Documention下的kobjct.txt，并加上了一些自己的注释，这样基本就对kobject 和sysfs有了一个比较深刻的理解，我们可以简单的将sysfs看成最bottom的操作，然后kobject的想关操作是架构在sysfs 之上，再然后kobject和attribute所嵌入的结构体再构成上一层结构来操作kobject，最后就实现了kernel内部各个portion 通过sysfs与userspace进行交互。 要想了解linux驱动模型，以及驱动模型之上的kobject抽象，有一个难点就是我们没有一个明确的入手点。要想了解kobject 我们必须了解很多不同的类型，而这些类型之间又会交叉引用，所以为了让理解更容易我们从多方面入手，首先看一些可能模糊不清的概念，然后随着深入我们会加入细节，在最后我们会定义一些我们工作上需要使用的术语。 kobject是一个结构体，它包含name，reference count以及指向一个parent的指针(这个指针等于就是将kobject加入了一个体系结构中)，一个特定的类型，以及在sysfs文件系统中的一个相关表达。kobject一般不会单独使用，大部分的时候它会被嵌入其他的结构体，而这些结构体才是我们代码中真正需要的。一个结构体最多只能嵌入一个kobject，不然reference count就会乱掉，出错。 (PS：实际上我们可以理解这个kobject实际上是我们与sysfs进行交互的一个接口，我们在设备驱动以及总线相关的结构体中嵌入这个kobject，那么我们的设备驱动就可以通过sysfs与userspace进行交互了。虽然sysfs是kobject的表达，但我们可以近似的将kobject看成是架在sysfs上面的，在kobject上面封装的一系列操作实际上到底层都是调用的sysfs的公共接口) struct kobject { const char *name; struct list_head entry; struct kobejct *parent; struct kset *kset; struct kobj_type *ktype; struct sysfs_dirent *sd; struct kref kref; unsigned int state_initialized:1; unsigned int state_in_sysfs:1; unsigned int state_add_uevent_sent:1; unsigend int state_remove_uevent_sent:1; } ktype定义了嵌入了kobject的结构体的类型，每一个嵌入了kobject的结构体都必须有一个想对应的ktype，ktype定义了这个kobject创建和销毁时候需要做的事情。
编写嵌入式Linux设备驱动程序的实例教程 一、Linux device driver 的概念 系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以象操作普通文件一样对硬件设备进行操作。设备驱动程序是内核的一部分，它完成以下的功能: 1、对设备初始化和释放； 2、把数据从内核传送到硬件和从硬件读取数据； 3、读取应用程序传送给设备文件的数据和回送应用程序请求的数据； 4、检测和处理设备出现的错误。 在linux操作系统下有三类主要的设备文件类型，一是字符设备，二是块设备，三是网络设备。字符设备和块设备的主要区别是:在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了，块设备则不然，它利用一块系统内存作缓冲区，当用户进程对设备请求能满足用户的要求，就返回请求的数据，如
果不能，就调用请求函数来进行实际的I/O操作。块设备是主要针对磁盘等慢速设备设计的，以免耗费过多的CPU时间来等待。 已经提到，用户进程是通过设备文件来与实际的硬件打交道。每个设备文件都都有其文件属性(c/b)，表示是字符设备还是块设备?另外每个文件都有两个设备号，第一个是主设备号，标识驱动程序，第二个是从设备号，标识使用同一个设备驱动程序的不同的硬件设备，比如有两个软盘，就可以用从设备号来区分他们。设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号一致，否则用户进程将无法访问到驱动程序。 最后必须提到的是，在用户进程调用驱动程序时，系统进入核心态，这时不再是抢先式调度。也就是说，系统必须在你的驱动程序的子函数返回后才能进行其他的工作。如果你的驱动程序陷入死循环，不幸的是你只有重新启动机器了，然后就是漫长的fsck。 二、实例剖析 我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理。把