Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1743484
  • 博文数量: 1493
  • 博客积分: 38
  • 博客等级: 民兵
  • 技术积分: 5834
  • 用 户 组: 普通用户
  • 注册时间: 2009-08-19 17:28
文章分类

全部博文(1493)

文章存档

2016年(11)

2015年(38)

2014年(137)

2013年(253)

2012年(1054)

2011年(1)

分类:

2012-08-01 16:22:56

原文地址:udev的实现原理 作者:bough22

udev的实现原理1kobject, ktype, kset

kobject代表sysfs中的目录。

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变量。

2uevent内核部分

ueventsysfs向用户空间发出的消息。比如,device_add函数中,会调用kobject_uevent(&dev->kobj, KOBJ_ADD); 这里kobj是发消息的kobjKOBJ_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);

                                       //KOBJ_ADD, KOBJ_REMOVE,KOBJ_CHANGE,

}

 

kobject_uevent_env:

       kobjectparent向上查找,直到找到一个kobject包含kset

       如果kset中有filter函数,调用filter函数,看看是否需要过滤uevent消息。

       如果kset中有name函数,调用name函数得到subsystem的名字;否则,subsystem的名字是ksetkobject的名字。

       分配一个kobj_uevent_env,并开始填充env环境变量:

       增加环境变量ACTION=

       增加环境变量DEVPATH=

       增加环境变量SUBSYSTEM=

       增加环境变量kobject_uevent_env中参数envp_ext指定的环境变量。

       调用ksetuevent函数,这个函数会继续填充环境变量。

       增加环境变量SEQNUM=,这里seq是静态变量,每次累加。

       调用netlink发送uevent消息。

       调用uevent_helper,最终转换成对用户空间sbin/mdev的调用。

3uevent用户空间部分

uevent的用户空间程序有两个,一个是udev,一个是mdev

udev通过netlink监听uevent消息,它能完成两个功能:

       1.自动加载模块

       2.根据uevent消息在dev目录下添加、删除设备节点。

另一个是mdevmdevbusybox的代码包中能找到,它通过上节提到的uevent_helper函数被调用。

 

下面简要介绍udev的模块自动加载过程:

etc目录下有一个uevent规则文件/etc/udev/rules.d/50-udev.rules

udev程序收到uevent消息后,在这个规则文件里匹配,如果匹配成功,则执行这个匹配定义的shell命令。例如,规则文件里有这么一行:

ACTION=="add", SUBSYSTEM=="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}"

所以,当收到ueventadd事件后,shell能自动加载在MODALIAS中定义的模块。

 

mdev的模块自动加载过程与之类似,它的配置文件在/etc/mdev.conf中。例如:

$MODALIAS=.* 0:0 660 @modprobe "$MODALIAS"

这条规则指的是:当收到的环境变量中含有MODALIAS,那么加载MODALIAS代表的模块。

mdev的详细说明在busyboxdocs/mdev.txt中。

4uevent在设备驱动模型中的应用

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中,主要是规定了要想发送ueventdev必须有class或者bus

dev_uevent_name中,返回devclass或者bus的名字。

dev_uevent函数:

       如果dev有设备号,添加环境变量MAJORMINOR

       如果dev->type有值,设置DEVTYPE=<dev->type->name>

       如果dev->driver,设置DRIVER=<dev->driver->name>

       如果有bus,调用busuevent函数。

       如果有class,调用classuevent函数。

如果有dev->type,调用dev->type->uevent函数。

 

一般在busuevent函数中,都会添加MODALIAS环境变量,设置成dev的名字。这样,uevent传到用户空间后,就可以通过对MODALIAS的匹配自动加载模块。这样的bus例子有platformI2C等等。
阅读(233) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~