linux驱动编程--设备模型1

        最近学习设备模型的运行机制,进过书上和网上资料的训练,貌似已经修改出了自己的网络权值,所以写了下来并整理一下自己的思路。

        之前的驱动程序由于硬件信息和逻辑操作是写在一起的,所以一个驱动只能适应一种平台。为了提高驱动程序的可移植性,就引出了设备模型。

        那么现在面临的问题是:设备模型是怎么工作的?

一.理论

        这就要谈到两个重要的结构体kobject和kset。

        1.1 kobject

                 kobject是设备对象的基础结构体。很多的kobject对象连接在一起构成了一个分级的拓扑结构,相当于这栋建筑的钢架,负责各个对象间的连接工作。

         struct kobject;
         struct kobject {
                  const char        *name;             //
                  struct list_head  entry;            //内核链表的入口,通过container_of()
                  struct kobject    *parent; //父对象,用于构建kobject对象的层级关系
                    struct kset 	 *kset;	         //kobject对象所属的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;          //
                  unsigned int state_remove_uevent_sent:1;
                  unsigned int uevent_suppress:1;                //是否发送通知事件
         };

                对应的操作函数如下

        kobject_set_name(struct kobject * kobj,const char * fmt,...);
        kobject_init(struct kobject * kobj,struct kobj_type * ktype);
        kobject_add(struct kobject * kobj,struct kobject * parent,const char * fmt,...);//1).保证kobject的层次关系。2).在sysfs中建立对应目录
        kobject_del(struct kobject * kobj);

                其中的kobject_add()函数会将新的kobject对象添加到这栋建筑的对应层级中,且还会在sysfs中建立对应的目录。关于属性文件,它存在的意义是为用户提供了一种与驱动模型交互的方式。在之前的驱动模型中,应用层与驱动层的交互是依靠设备文件来完成,典型交互过程就是:

                        打开设备文件 -->  向设备文件读写操作  -->  关闭设备文件

                对设备进行读写的时候,会将数据传输到内核层的驱动处理函数处。有了属性文件后就可以有另外一种交互方式:

                        cat /sys/(设备模型的对应目录)/(对应的属性文件)

                        echo ‘xx‘ > /sys/(设备模型的对应目录)/(对应的属性文件)

                对属性文件的读写最终会调用到"对应的"kobject对象的ktype成员下的操作函数(show或store)。这样就通过对属性文件的操作实现了与内核中kobject对象的交流。(在下面的例子中会有演示)

 

        1.2 kset

                kset是一个容器放有所有同类型的kobject对象,相当于这栋建筑的一个楼层。

        struct kset {
                struct list_head list;        //同类型的kobject链表
                spinlock_t list_lock;        //
                struct kobject kobj;        //本身所属的kobject对象
                struct kset_uevent_ops *uevent_ops;        //通知事件的操作函数
        };

        struct kset_uevent_ops {        //在kobject_uevent()中先后调用函数1和函数3
                int (*filter)(struct kset *kset, struct kobject *kobj);                //函数1
                const char *(*name)(struct kset *kset, struct kobject *kobj);
                int (*uevent)(struct kset *kset, struct kobject *kobj,                //函数3
                                        struct kobj_uevent_env *env);
        };

 

               在有些时候我们需要将一个kobject对象的变化通知到应用层(比如热插拔事件,然后在应用层会查找并加载相应驱动程序),这时就需要调用kobject_uevent()函数。
该函数会找到该kobject对象所属的kset集合。然后分别调用uevent_ops成员下的filter函数(),和uevent函数()。最终会调用call_usermodehelper()。在call_usermodehelper会根据指定的路径将一个用户空间的程序带进内核空间执行,从而完成事件的通知。函数主干如下(注意英语注释)

	kobject_uevent(struct kobject * kobj,enum kobject_action action);
	{
		......
		/* search the kset we belong to */
		top_kobj = kobj;
		while (!top_kobj->kset && top_kobj->parent)
			top_kobj = top_kobj->parent;
                  ......
		kset = top_kobj->kset;
		uevent_ops = kset->uevent_ops;
		/* skip the event, if the filter returns zero. */
		if (uevent_ops && uevent_ops->filter)
			if (!uevent_ops->filter(kset, kobj)) {
				pr_debug("kobject: ‘%s‘ (%p): %s: filter function "
					 "caused the event to drop!\n",
					 kobject_name(kobj), kobj, __func__);
				return 0;
			}
		......
		/* let the kset specific function add its stuff */
		if (uevent_ops && uevent_ops->uevent) {
			retval = uevent_ops->uevent(kset, kobj, env);//完成kset对象的私人事件
			if (retval) {
				pr_debug("kobject: ‘%s‘ (%p): %s: uevent() returned "
					 "%d\n", kobject_name(kobj), kobj,
					 __func__, retval);
				goto exit;
			}
		}
		......
		......
		/* 调用用户空间的程序*/
                  argv [0] = uevent_helper;	 //这里指定了应用层程序的路径
		retval = call_usermodehelper(argv[0], argv,
						 env->envp, UMH_WAIT_EXEC);
		......
	}

                 kobject_uevent与上层的交流实际就是在内核为应用层的程序建立一个线程。而这个应用程序由 uevent_helper 变量指定。那么怎么修改这个内核变量呢,这就涉及到另外一个点。

                 在内核运行的过程中会有一些全局变量,这些全局变量的确定着内核的运行方式。在linux内核编写时为了给用户层留出他们的接口,就将这些变量以及内核信息虚拟成了一个文件放在"/proc/sys/kernel/" 目录下。当然也有可能在 "/sys/kernel/" 目录下,他们在这个功能方面有一些重复。关于proc目录的具体信息可以 "man proc" 来查看。

                 现在继续回来讨论 uevent_helper变量的修改,经过查找在 "/sys/kernel" 下发现了uevent_helper,又在 "/proc/sys/kernel/" 下发现了hotplug。对这两个的修改都能修改到内核中的uevent_helper变量。


二. 例子 

         现在制作一个具体的测试程序来检验一下。

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/kobject.h>
#include <linux/sysfs.h>
#include <linux/slab.h>


#define NAME_PARENT		"dem_parent"	//parent 对象

#define NAME_CHILD		"dem_child"	//child 对象

#define NAME_SET		"dem_set"	//child 对象所属的kset集合

#define NAME_CHATTR		"child_attr"	//child 对象的属性文件



static struct kobject *parent;
static struct kobject *child;
static struct kset	*c_kset;

static int flag = 0;

static ssize_t attr_show(struct kobject *kobj, struct attribute *attr,char *buf)
{
	ssize_t size = 0;
	size = sprintf( buf, "%d\n", flag);

	return size;

}

static ssize_t attr_store(struct kobject *kobj,struct attribute *attr,const char *buf, size_t len)
{
	//printk( "kobject: %x,  kchild: %x\n", kobj, child);
	int	old_flag = flag;
	flag = buf[0]-‘0‘;
	//将从属性文件传下来的信息通知会应用层,进而验证热插拔
	switch( flag)
	{
		case 0:
			kobject_uevent( kobj,  KOBJ_ADD);
			break;
		case 1:
			kobject_uevent( kobj,  KOBJ_REMOVE);
			break;
		case 2:
			kobject_uevent( kobj,  KOBJ_CHANGE);
			break;
		case 3:
			kobject_uevent( kobj,  KOBJ_MOVE);
			break;
		case 4:
			kobject_uevent( kobj,  KOBJ_ONLINE);
			break;
		case 5:
			kobject_uevent( kobj,  KOBJ_OFFLINE);
			break;

		default :
			break;
	}

	return old_flag;

}


//child对象的属性文件
static struct attribute kchild_attr[] = {
	{
		.name = NAME_CHATTR,
		.mode = S_IRUGO|S_IWUGO,
	}
};
//child对象属性文件的操作函数
static struct sysfs_ops kchild_ops = {
	.show = attr_show,
	.store = attr_store,
};

static struct kobj_type kchild_type = {
	.sysfs_ops = &kchild_ops,
};

static int __init demo_init( void)
{
	printk("load vision: %s\n", __TIME__);

	//创建一个kobject对象作为child对象的父对象
	parent = kobject_create_and_add( NAME_PARENT, NULL);
	if( NULL==parent )
	{
		printk("error: %s, %d\n", __FILE__, __LINE__);
		goto ERR_KPARENT;
	}
	//如果child对象要进行事件通知,就必须属于一个kset集合
	c_kset = kset_create_and_add( NAME_SET, NULL, parent);
	if( NULL==c_kset)
	{
		printk("error: %s, %d\n", __FILE__, __LINE__);
		goto ERR_KSET;
	}

	child = kzalloc(sizeof(*child), GFP_KERNEL);
	if (!child)
	{
		printk("error: %s, %d\n", __FILE__, __LINE__);
		goto ERR_KCHILD;
	}

	int	retval;
	child->kset = c_kset;
	retval = kobject_init_and_add( child, &kchild_type, parent, NAME_CHILD);
	if (retval) {
		printk("error: %s, %d\n", __FILE__, __LINE__);
		goto ERR_CHILDADD;
	}
	//创建child对象对应的属性文件
	retval = sysfs_create_file( child, &kchild_attr);

	OUT:
		return retval;


	ERR_CHILDADD:
		kobject_put(child);
		child = NULL;
	ERR_KCHILD:
		kset_unregister( c_kset);
		c_kset = NULL;
	ERR_KSET:
		kobject_del( parent);
		parent = NULL;
	ERR_KPARENT:
		return -1;	
}


static void __exit demo_exit( void)
{
	printk("unload vision: %s\n", __TIME__);

	kobject_del( child);
	kset_unregister( c_kset);
	kobject_del( parent);
}



MODULE_LICENSE("GPL");


module_init(demo_init);
module_exit(demo_exit);



        程序思路按照一般的驱动加载思路执行。最终这个程序会在 /sys/目录下建立 dem_parent文件夹,再在其下建立 dem_child 和dem_set两个文件夹。并建立了属性文件/sys/dem_parent/dem_child/child_attr。当我们执行"echo ‘1‘ > /sys/dem_parent/dem_child/child_attr" 时,消息会通知到内核的child对象处,并调用store处理函数。这就完成了应用层到内核层的沟通。

        而内核层到用户层的沟通,通过kobject_uevent()来实现。在store函数中,我们已经调用了该函数。其会去指定路径下找到相应的程序或脚本文件,并在内核空间中构建进程。这样就完成了内核到用户空间的交流。经过查找发现了应用层程序的路径由uevent_helper变量指定,去/sys/kernel目录下果然找到了一个文件uevent_helper,这应该就是留给应用层的接口。现在输入:"echo ‘/sbin/XXX‘ > /sys/kernel/uevent_helper",当我们再次执行"echo ‘1‘ > /sys/dem_parent/dem_child/child_attr"时就会发现自己在在应用层设置的程序或脚本被调用了(记得修改程序或脚本的可执行权限)。

 

 

 

 

 

 


 

 

 

 

 

 

linux驱动编程--设备模型1,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。