在Linux系统中，当系统配置发生变化时,如:添加kset到系统；移动kobject, 一个通知会从内核空间发送到用户空间,这就是热插拔事件。热插拔事件会导致用户空间中相应的处理程序(如udev,mdev)被调用, 这些处理程序会通过加载驱动程序, 创建设备节点等来响应热插拔事件。
*** 作集合
Struct kset_uevent_ops {
int (*filter)(struct kset *kset, struct kobject *kobj)
const char *(*name)(struct kset *kset, struct kobject *kobj)
int (*uevent)(struct kset *kset, struct kobject *kobj,
struct kobj_uevent_env *env)
}
当该kset所管理的kobject和kset状态发生变化时（如被加入，移动），这三个函数将被调用。
Filter：决定是否将事件传递到用户空间。如果filter返回0,将不传递事件。
Name：负责将相应的字符串传递给用户空间的热插拔处理程序。
Uevent：将用户空间需要的参数添加到环境变量中。
int (*uevent)(struct kset *kset,
struct kobject *kobj, /*产生事件的目标对象*/
char **envp, /*一个保存其他环境变量定义(通常为NAME=value的格式)的数组*/
int num_envp, /*环境变量数组中包含的变量数（数组大小）*/
char *buffer, int buffer_size/*环境变量被放入的缓冲区的指针和字节数*/
)/*返回值正常时是，若返回非零值将终止热插拔事件的产生*/
实例源码： temp.rar
请点击输入图片描述
点击(此处)折叠或打开
/**
* 热插拔事件
* Lzy 2012-7-27
*/
#include <linux/device.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/string.h>
#include <linux/sysfs.h>
#include <linux/stat.h>
#include <linux/kobject.h>
static struct attribute test_attr =
{
.name = "kobj_config",
.mode = S_IRWXUGO,
}
static struct attribute *def_attrs[] =
{
&test_attr,
NULL,
}
ssize_t kobj_test_show(struct kobject *kobject,struct attribute *attr,char *buf)
{
printk("Have show -->\n")
printk("attrname: %s.\n",attr->name)
sprintf(buf,"%s\n",attr->name)
return strlen(attr->name) + 2
}
ssize_t kobj_test_store(struct kobject *kobject,struct attribute *attr, const char *buf,size_t size)
{
printk("Have store -->\n")
printk("write: %s.\n",buf)
return size
}
static struct sysfs_ops obj_test_sysops =
{
.show = kobj_test_show,
.store = kobj_test_store,
}
void obj_test_release(struct kobject *kobject)
{
printk("[kobj_test: release!]\n")
}
static struct kobj_type ktype =
{
.release = obj_test_release,
.sysfs_ops = &obj_test_sysops,
.default_attrs = def_attrs,
}
static int kset_filter(struct kset *kset,struct kobject *kobj)
{
// int ret=0
// struct kobj_type *ktype = get_ktype(kobj) /* 得到属性类型 */
// ret = (ktype == &ktype_part)
printk("Filter: kobj %s.\n",kobj->name)
return 1
}
static const char *kset_name(struct kset *kset,struct kobject *kobj)
{
static char buf[20]
/* struct device *dev = to_dev(kobj)
if(dev->bus)
return dev->bus->name
else if(dev->class)
return dev->class->name
else
*/ {
printk("Name kobj %s.\n",kobj->name)
sprintf(buf,"%s","kset_name")
}
return buf
}
static int kset_uevent(struct kset *kset,struct kobject *kobj, struct kobj_uevent_env *env)
{
int i = 0
printk("uevent: kobj %s.\n",kobj->name)
while(i < env->envp_idx)
{
printk("%s.\n",env->envp[i])
i ++
}
return 0
}
static struct kset_uevent_ops uevent_ops =
{
.filter = kset_filter,
.name = kset_name,
.uevent = kset_uevent,
}
struct kset *kset_p
struct kset kset_c
static int __init kset_test_init(void)
{
int ret = 0
printk("kset test init!\n")
/* 创建并注册 kset_p */
kset_p = kset_create_and_add("kset_p", &uevent_ops, NULL)
kobject_set_name(&kset_c.kobj,"kset_c")
kset_c.kobj.kset = kset_p /* 添加 kset_c 到 kset_p */
/* 对于较新版本的内核，在注册 kset 之前，需要
* 填充 kset.kobj 的 ktype 成员，否则注册不会成功 */
kset_c.kobj.ktype = &ktype
ret = kset_register(&kset_c)
if(ret)
kset_unregister(kset_p)
return ret
}
static void __exit kset_test_exit(void)
{
printk("kset test exit!\n")
kset_unregister(&kset_c)
kset_unregister(kset_p)
}
module_init(kset_test_init)
module_exit(kset_test_exit)
MODULE_AUTHOR("Lzy")
MODULE_LICENSE("GPL")
USB驱动程序基础
在动手写USB驱动程序这前，让我们先看看写的USB驱动程序在内核中的结构，如下图：
USB驱动程序存在于不同的内核子系统和USB硬件控制器之间，USB核心为USB驱动程序提供了一个用于访问和控制USB硬件的接口，而不必考虑系统当前存在的各种不同类型的USB硬件控制器。USB是一个非常复杂的设备，linux内核为我们提供了一个称为USB的核心的子系统来处理大部分的复杂性，USB设备包括配置(configuration)、接口（interface）和端点(endpoint)，USB设备绑定到接口上，而不是整个USB设备。如下图所示：
USB通信最基本的形式是通过端点（USB端点分中断、批量、等时、控制四种，每种用途不同），USB端点只能往一个方向传送数据，从主机到设备或者从设备到主机，端点可以看作是单向的管道（pipe）。所以我们可以这样认为：设备通常具有一个或者更多的配置，配置经常具有一个或者更多的接口，接口通常具有一个或者更多的设置，接口没有或具有一个以上的端点。驱动程序把驱动程序对象注册到USB子系统中，稍后再使用制造商和设备标识来判断是否已经安装了硬件。USB核心使用一个列表（是一个包含制造商ID和设备号ID的一个结构体）来判断对于一个设备该使用哪一个驱动程序，热插拨脚本使用它来确定当一个特定的设备插入到系统时该自动装载哪一个驱动程序。
上面我们简要说明了驱动程序的基本理论，在写一个设备驱动程序之前，我们还要了解以下两个概念：模块和设备文件。
模块：是在内核空间运行的程序，实际上是一种目标对象文件，没有链接，不能独立运行，但是可以装载到系统中作为内核的一部分运行，从而可以动态扩充内核的功能。模块最主要的用处就是用来实现设备驱动程序。Linux下对于一个硬件的驱动，可以有两种方式：直接加载到内核代码中，启动内核时就会驱动此硬件设备。另一种就是以模块方式，编译生成一个.ko文件(在2.4以下内核中是用.o作模块文件，我们以2.6的内核为准，以下同)。当应用程序需要时再加载到内核空间运行。所以我们所说的一个硬件的驱动程序，通常指的就是一个驱动模块。
设备文件：对于一个设备，它可以在/dev下面存在一个对应的逻辑设备节点，这个节点以文件的形式存在，但它不是普通意义上的文件，它是设备文件，更确切的说，它是设备节点。这个节点是通过mknod命令建立的，其中指定了主设备号和次设备号。主设备号表明了某一类设备，一般对应着确定的驱动程序；次设备号一般是区分不同属性，例如不同的使用方法，不同的位置，不同的 *** 作。这个设备号是从/proc/devices文件中获得的，所以一般是先有驱动程序在内核中，才有设备节点在目录中。这个设备号（特指主设备号）的主要作用，就是声明设备所使用的驱动程序。驱动程序和设备号是一一对应的，当你打开一个设备文件时， *** 作系统就已经知道这个设备所对应的驱动程序。对于一个硬件，Linux是这样来进行驱动的：首先，我们必须提供一个.ko的驱动模块文件。我们要使用这个驱动程序，首先要加载它，我们可以用insmod
xxx.ko，这样驱动就会根据自己的类型（字符设备类型或块设备类型，例如鼠标就是字符设备而硬盘就是块设备）向系统注册，注册成功系统会反馈一个主设备号，这个主设备号就是系统对它的唯一标识。驱动就是根据此主设备号来创建一个一般放置在/dev目录下的设备文件。在我们要访问此硬件时，就可以对设备文件通过open、read、write、close等命令进行。而驱动就会接收到相应的read、write *** 作而根据自己的模块中的相应函数进行 *** 作了。
USB驱动程序实践
了解了上述理论后，我们就可以动手写驱动程序，如果你基本功好，而且写过linux下的硬件驱动，USB的硬件驱动和pci_driver很类似，那么写USB的驱动就比较简单了，如果你只是大体了解了linux的硬件驱动，那也不要紧，因为在linux的内核源码中有一个框架程序可以拿来借用一下，这个框架程序在/usr/src/~（你的内核版本，以下同）/drivers/usb下，文件名为usb-skeleton.c。写一个USB的驱动程序最基本的要做四件事：驱动程序要支持的设备、注册USB驱动程序、探测和断开、提交和控制urb（USB请求块）（当然也可以不用urb来传输数据，下文我们会说到）。
驱动程序支持的设备：有一个结构体struct
usb_device_id，这个结构体提供了一列不同类型的该驱动程序支持的USB设备，对于一个只控制一个特定的USB设备的驱动程序来说，struct
usb_device_id表被定义为：
/* 驱动程序支持的设备列表 */
static struct usb_device_id
skel_table [] = {
{ USB_DEVICE(USB_SKEL_VENDOR_ID, USB_SKEL_PRODUCT_ID)
},
{ } /* 终止入口 */
}
MODULE_DEVICE_TABLE (usb,
skel_table)
对于PC驱动程序，MODULE_DEVICE_TABLE是必需的，而且usb必需为该宏的第一个值，而USB_SKEL_VENDOR_ID和USB_SKEL_PRODUCT_ID就是这个特殊设备的制造商和产品的ID了，我们在程序中把定义的值改为我们这款USB的，如：
/*
定义制造商和产品的ID号 */
#define USB_SKEL_VENDOR_ID 0x1234
#define
USB_SKEL_PRODUCT_ID
0x2345
这两个值可以通过命令lsusb，当然你得先把USB设备先插到主机上了。或者查看厂商的USB设备的手册也能得到，在我机器上运行lsusb是这样的结果：
Bus
004 Device 001: ID 0000:0000
Bus 003 Device 002: ID 1234:2345 Abc Corp.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID
0000:0000
得到这两个值后把它定义到程序里就可以了。
注册USB驱动程序：所有的USB驱动程序都必须创建的结构体是struct
usb_driver。这个结构体必须由USB驱动程序来填写，包括许多回调函数和变量，它们向USB核心代码描述USB驱动程序。创建一个有效的struct
usb_driver结构体，只须要初始化五个字段就可以了，在框架程序中是这样的：
static struct usb_driver skel_driver
= {
.owner = THIS_MODULE,
.name = "skeleton",
.probe = skel_probe,
.disconnect = skel_disconnect,
.id_table = skel_table,
}
ktype代表kobject的类型，主要包含release函数和attr的读写函数。比如，所有的bus都有同一个bus_type；所有的class都有同一个class_type。kset包含了subsystem概念，kset本身也是一个kobject，所以里面包含了一个kobject对象。另外，kset中包含kset_uevent_ops，里面主要定义了三个函数 int (*filter)(struct kset *kset, struct kobject *kobj)const char *(*name)(struct kset *kset, struct kobject *kobj)int (*uevent)(struct kset *kset, struct kobject *kobj, struct kobj_uevent_env *env)这三个函数都与uevent相关。filter用于判断uevent是否要发出去。name用于得到subsystem的名字。uevent用于填充env变量。2．uevent内核部分uevent是sysfs向用户空间发出的消息。比如，device_add函数中，会调用kobject_uevent(&dev->kobj, KOBJ_ADD)这里kobj是发消息的kobj，KOBJ_ADD是发出的事件。uevent的事件在kobject_action中定义：enum kobject_action { KOBJ_ADD, KOBJ_REMOVE, KOBJ_CHANGE, KOBJ_MOVE, KOBJ_ONLINE, KOBJ_OFFLINE, KOBJ_MAX}int kobject_uevent(struct kobject *kobj, enum kobject_action action){ return kobject_uevent_env(kobj, action, NULL)} kobject_uevent_env: 由kobject的parent向上查找，直到找到一个kobject包含kset。 如果kset中有filter函数，调用filter函数，看看是否需要过滤uevent消息。 如果kset中有name函数，调用name函数得到subsystem的名字；否则，subsystem的名字是kset中kobject的名字。 分配一个kobj_uevent_env，并开始填充env环境变量： 增加环境变量ACTION=<action name>增加环境变量DEVPATH=<kobj’s path>增加环境变量SUBSYSTEM=<subsystem name>增加环境变量kobject_uevent_env中参数envp_ext指定的环境变量。 调用kset的uevent函数，这个函数会继续填充环境变量。 增加环境变量SEQNUM=<seq>，这里seq是静态变量，每次累加。 调用netlink发送uevent消息。 调用uevent_helper，最终转换成对用户空间sbin/mdev的调用。3．uevent用户空间部分uevent的用户空间程序有两个，一个是udev，一个是mdev。udev通过netlink监听uevent消息，它能完成两个功能： 1．自动加载模块 2．根据uevent消息在dev目录下添加、删除设备节点。另一个是mdev，mdev在busybox的代码包中能找到，它通过上节提到的uevent_helper函数被调用。 下面简要介绍udev的模块自动加载过程：etc目录下有一个uevent规则文件/etc/udev/rules.d/50-udev.rulesudev程序收到uevent消息后，在这个规则文件里匹配，如果匹配成功，则执行这个匹配定义的shell命令。例如，规则文件里有这么一行：ACTION=="add", SUBSYSTEM=="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}"所以，当收到uevent的add事件后，shell能自动加载在MODALIAS中定义的模块。 mdev的模块自动加载过程与之类似，它的配置文件在/etc/mdev.conf中。例如：$MODALIAS=.* 0:0 660 @modprobe "$MODALIAS"这条规则指的是：当收到的环境变量中含有MODALIAS，那么加载MODALIAS代表的模块。mdev的详细说明在busybox的docs/mdev.txt中。4．uevent在设备驱动模型中的应用在sys目录下有一个子目录devices，代表一个kset。创建设备时，调用的device_initialize函数中，默认会把kset设置成devices_kset，即devices子目录代表的kset。devices_kset中设置了uevent *** 作集device_uevent_ops。static struct kset_uevent_ops device_uevent_ops = { .filter = dev_uevent_filter, .name = dev_uevent_name, .uevent = dev_uevent,}dev_uevent_filter中，主要是规定了要想发送uevent，dev必须有class或者bus。dev_uevent_name中，返回dev的class或者bus的名字。dev_uevent函数： 如果dev有设备号，添加环境变量MAJOR与MINOR。 如果dev->type有值，设置DEVTYPE=<dev->type->name>。 如果dev->driver，设置DRIVER=<dev->driver->name>。 如果有bus，调用bus的uevent函数。 如果有class，调用class的uevent函数。如果有dev->type，调用dev->type->uevent函数。 一般在bus的uevent函数中，都会添加MODALIAS环境变量，设置成dev的名字。这样，uevent传到用户空间后，就可以通过对MODALIAS的匹配自动加载模块。欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）