转自:http://www.cnblogs.com/hnrainll/archive/2011/06/10/2077469.html
转自:http://blog.chinaunix.net/space.php?uid=20543672&do=blog&cuid=460882
热插拔
有 2 个不同角度来看待热插拔:
从内核角度看,热插拔是在硬件、内核和内核驱动之间的交互。
从用户角度看,热插拔是内核和用户空间之间,通过调用用户空间程序(如hotplug、udev 和 mdev)的交互。 当需要通知用户内核发生了某种热插拔事件时,内核才调用这个用户空间程序。
现在的计算机系统,要求 Linux 内核能够在硬件从系统中增删时,可靠稳定地运行。这就对设备驱动作者增加了压力,因为在他们必须处理一个毫无征兆地突然出现或消失的设备。
热插拔工具
当用户向系统添加或删除设备时,内核会产生一个热插拔事件,并在 /proc/sys/kernel/hotplug 文件里查找处理设备连接的用户空间程序。这个用户空间程序主要有
hotplug:这个程序是一个典型的 bash 脚本, 只传递执行权给一系列位于 /etc/hot-plug.d/ 目录树的程序。hotplug 脚本搜索所有的有 .hotplug 后缀的可能对这个事件进行处理的程序并调用它们, 并传递给它们许多不同的已经被内核设置的环境变量。(基本已被淘汰,具体内容请参阅《LDD3》)
《UDEV Primer》(英文),地址:http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html
《udev规则编写》(luofuchong翻译),地址:http://www.cnitblog.com/luofuchong/archive/2007/12/18/37831.html
《udev-FAQ 中文翻译》地址:http://gnawux.bokee.com/3225765.html
在《LFS》中也有介绍udev的使用,很值得参考!下载地址:http://lfs.osuosl.org/lfs/downloads/stable/
|
因为hotplug现在也在被慢慢地淘汰,udev不再依赖hotplug了,所以这里不再介绍;
udev较mdev复杂,不太适合嵌入式使用。(本人也有做udev的实验,交叉编译是通过了,但是使用上有问题,没有实现其功能。也许是我的文件系统没做好,以后有时间再研究和写记录。有成功高人的通知一声,交流一下经验。^_^谢谢!);
mdev简单易用,比较适合嵌入式系统,实验成功。以下详细介绍mdev的使用。
源码的bug(个人意见):由于mdev是通过判断“dev”属性文件的路径字符串中的第6个字符是否为‘c’,来决定设备是字符设备还是块设备【type = (path[5] == 'c' ? S_IFCHR : S_IFBLK);例如path = "/sys/class/ldd/sculld*/"为字符设备,而/sys/devices/ldd0/sculld*/ 就会被误判为块设备】,那么如果你在非 /sys/class 和 /sys/block 目录下建立了“dev”属性文件且内容是设备号(像sculld中就这样做了),那么mdev也会在/dev 下创建设备节点文件。这样可能所创建的设备节点文件是错的。 以我实验为例,我以上一篇的文章中的sculld为基础,加上了类接口(这样在/sys/devices/ldd0/sculld*/和 /sys/class/ldd/sculld* 中都有内容为设备号的“dev”属性文件)。 在运行时发现一直会将有的sculld*创建为块设备节点文件。郁闷死了,难道我的驱动有错???最后研究了mdev源码之后发现,只要在 /sys中建立了“dev”属性文件且内容是设备号,mdev就会以所在的目录为名在/dev 下创建设备节点文件。像sculld模块,mdev会为一个设备创建两次设备文件,由于文件名一样,第二次的文件会覆盖第一次的。如果第二次是因为/sys/devices/ldd0/sculld*/dev 产生的设备节点文件,那么设备节点文件就会被错误地创建为块设备。 我认为这个bug的解决办法有如下两种: (1)在你写驱动的时候,只在/sys/class 和 /sys/block 中的类设备目录中存在包含设备号的“dev”属性文件。(你无法保证被人的驱动会这么做) (2)修正mdev源码: 修改/busybox-1.9.0/util-linux/mdev.c文件的第328行:
也就是在增加设备节点文件之前检查/sys/目录下的路径是否为/class和/block(通过检查路径字符串的第3个字符是否为‘l’)。 本人推荐第二种做法! |
Linux System Utilities --->
[*] mdev
[*] Support /etc/mdev.conf
[*] Support command execution at device addition/removal
|
/bin/echo /sbin/mdev > /proc/sys/kernel/hotplug,并非
/bin/echo /bin/mdev > /proc/sys/kernel/hotplug。busybox的文档有错!!
|
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 接口允许使用驱动发布设备固件。当正确地集成进热插拔机制后, 固件加载子系统允许设备不受干扰地工作。显然这是处理问题的最好方法,但固件受版权保护,小心违反版权法。
实验现象:
|