【from 一只嵌入式爱好者】Linux字符设备驱动详解二（使用设备驱动模型）

文章介绍了Linux内核中的设备驱动模型，重点讲解了sysfs虚拟文件系统如何体现设备驱动模型，以及kobject、kset和kobj_type等基本元素的作用。通过示例代码展示了如何在驱动模块中构建设备文件系统，包括创建kset、kobject和属性文件的过程。

摘要由CSDN通过智能技术生成

原文地址：https://blog.csdn.net/weixin_45905650/article/details/121509019

文章目录

前言
驱动目录
正文
总结

前言

本文主要来自正点原子、野火Linux教程及本人理解，若有侵权请及时联系本人删除。

驱动目录

sys/kset_example/led_kobject/foo led

正文

为什么需要设备驱动模型

早期内核（2.4之前）没有统一的设备驱动模型，但照样可以用
2.4~2.6期间使用devfs，挂载在/dev目录。
- 需要在内核驱动中创建设备文件(devfs_register)，命名死板
2.6以后使用sysfs，挂载在/sys目录
- 将设备分类、分层次统一进行管理
- 配合udev/mdev守护进程动态创建设备文件，命令规则自由制定

sysfs概述

linux系统通过sysfs体现出设备驱动模型

sysfs是一个虚拟文件系统（类似proc文件系统）
目录对应的inode节点会记录基本驱动对象(kobject)，从而将系统中的设备组成层次结构
用户可以读写目录下的不同文件来配置驱动对象(kobject)的不同属性

设备驱动模型基本元素

kobject：sysfs中的一个目录，常用来表示基本驱动对象，不允许发送消息到用户空间
kset：sysfs中的一个目录，常用来管理kobject，允许发送消息到用户空间
kobj_type：目录下属性文件的操作接口

驱动模型一

在这里插入图片描述

kset可批量管理kobject
kobject无法批量管理kobject

驱动模型二

在这里插入图片描述

上层kobject节点无法遍历查找下层kobject

通常我们使用模型一，通过使用驱动模型，我们就不用再手动调用mknod命令创建设备文件(节点)

kobject

sysfs中每一个目录都对应一个kobject

struct kobject {
	//用来表示该kobject的名称
	const char		*name;
	//链表节点
	struct list_head	entry;
	//该kobject的上层节点，构建kobject之间的层次关系
	struct kobject		*parent;
	//该kobject所属的kset对象，用于批量管理kobject对象
	struct kset		*kset;
	//该Kobject的sysfs文件系统相关的操作和属性
	struct kobj_type	*ktype;
	//该kobject在sysfs文件系统中对应目录项
	struct kernfs_node	*sd; /* sysfs directory entry */
	//该kobject的引用次数
	struct kref		kref;
#ifdef CONFIG_DEBUG_KOBJECT_RELEASE
	struct delayed_work	release;
#endif
	//记录内核对象的初始化状态
	unsigned int state_initialized:1;
	//表示该kobject所代表的内核对象有没有在sysfs建立目录
	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;
};

kset

struct kset {
	//用来将其中的object对象构建成链表
	struct list_head list;
	//自旋锁
	spinlock_t list_lock;
	//当前kset内核对象的kobject变量
	struct kobject kobj;
	//定义了一组函数指针，当kset中的某些kobject对象发生状态变化需要通知用户空间时，调用其中的函数来完成
	const struct kset_uevent_ops *uevent_ops;
}

kobj_type

struct kobj_type {
	//销毁kobject对象时调用
	void (*release)(struct kobject *kobj);
	//kobject对象属性文件统一操作接口
	const struct sysfs_ops *sysfs_ops;
	//kobject默认属性文件的名字、"文件具体操作接口"
	struct attribute **default_attrs;                                                         
	const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
	const void *(*namespace)(struct kobject *kobj);
	void (*get_ownership)(struct kobject *kobj, kuid_t *uid, kgid_t *gid);
};

接下来我们就可以在驱动模块中完成设备文件系统的构建

首先从驱动模型中我们可以得知，kset作为kobject的容器，体现设备驱动的层次关系，通俗理解即sys/目录下的设备类型，我们通过kset_create_and_add()函数即可创建sys/目录下的一个设备类型目录

struct kset *kset_create_and_add(const char *name,
const struct kset_uevent_ops *uevent_ops,struct kobject *parent_kobj)
{
	struct kset *kset;
	int error;

	kset = kset_create(name, uevent_ops, parent_kobj);
	if (!kset)
		return NULL;

	error = kset_register(kset);
	if (error) {
		kfree(kset);
		return NULL;
	}
	return kset;
}

接着通过kobject_create_and_add()函数我们完成了构建一个kobject对象，构建一个sysfs中的目录项(kernfs_node)并把他们关联起来，通俗理解就是创建了一个具体的设备，即sys/设备类型/具体设备

struct kobject *kobject_create_and_add(const char *name, struct kobject *parent)
{
	struct kobject *kobj;
	int retval;
	/*创建并初始化一个kobject对象*/
	kobj = kobject_create();
	if (!kobj)
		return NULL;
	/*sysfs创建一个目录项并与kobject对象关联*/
	retval = kobject_add(kobj, parent, "%s", name);
	if (retval) {
		pr_warn("%s: kobject_add error: %d\n", __func__, retval);
		kobject_put(kobj);
		kobj = NULL;
	}
	return kobj;
}

最后需要完成为kobject对象构建多个属性文件，为每个属性文件设置具体操作接口以及vfs的inode对象与sysfs的kernfs_node对象的绑定过程。

对于这个过程我们首先构建多个kobj_attribute结构体，每个里面存放着具体属性的操作接口，将这些存放不同属性的结构体指针存放在attribute *类型的数组中，通过sysfs_create_group()函数我们可以调用数组指针完成不同属性文件的创建。

int sysfs_create_group(struct kobject *kobj,
		       const struct attribute_group *grp)
{
	return internal_create_group(kobj, 0, grp);
}

kobj_attribute结构体

struct kobj_attribute {
	struct attribute attr;
	ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
			char *buf);
	ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr,
			 const char *buf, size_t count);
};

代码示例

以野火设备驱动模型代码为例

#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/kobject.h>
#include <linux/string.h>
#include <linux/sysfs.h>
#include <linux/fs.h>
#include <linux/uaccess.h>
#include <asm/io.h>

#define DEV_MAJOR		0		/* 动态申请主设备号 */
#define DEV_NAME		"red_led" 	/*led设备名字 */

/* GPIO虚拟地址指针 */
static void __iomem *IMX6U_CCM_CCGR1;
static void __iomem *SW_MUX_GPIO1_IO04;
static void __iomem *SW_PAD_GPIO1_IO04;
static void __iomem *GPIO1_DR;
static void __iomem *GPIO1_GDIR;

static int foo;

static ssize_t foo_show(struct kobject *kobj, struct kobj_attribute *attr,
			char *buf)
{
	return sprintf(buf, "%d\n", foo);
}

static ssize_t foo_store(struct kobject *kobj, struct kobj_attribute *attr,
			 const char *buf, size_t count)
{
	int ret;

	ret = kstrtoint(buf, 10, &foo);
	if (ret < 0)
		return ret;

	return count;
}

static struct kobj_attribute foo_attribute =
	__ATTR(foo, 0664, foo_show, foo_store);


static ssize_t led_show(struct kobject *kobj, struct kobj_attribute *attr,
		      char *buf)
{
	int var;

	if (strcmp(attr->attr.name, "led") == 0)
			var =123;

	return sprintf(buf, "%d\n", var);
}

static ssize_t led_store(struct kobject *kobj, struct kobj_attribute *attr,
		       const char *buf, size_t count)
{

	if (strcmp(attr->attr.name, "led") == 0){
		if(!memcmp(buf,"on",2)) {	
			iowrite32(0 << 4, GPIO1_DR);	
		} else if(!memcmp(buf,"off",3)) {
			iowrite32(1 << 4, GPIO1_DR);
		}
	}
	return count;
}

static struct kobj_attribute led_attribute =
	__ATTR(led, 0664, led_show, led_store);

static struct attribute *attrs[] = {
	&foo_attribute.attr,
	&led_attribute.attr,
	NULL,	/* need to NULL terminate the list of attributes */
};

static struct attribute_group attr_group = {
	.attrs = attrs,
};

static struct kobject *led_kobj;

static int __init led_init(void)
{
	int retval;

	/* GPIO相关寄存器映射 */
  	IMX6U_CCM_CCGR1 = ioremap(0x20c406c, 4);
	SW_MUX_GPIO1_IO04 = ioremap(0x20e006c, 4);
  	SW_PAD_GPIO1_IO04 = ioremap(0x20e02f8, 4);
	GPIO1_GDIR = ioremap(0x0209c004, 4);
	GPIO1_DR = ioremap(0x0209c000, 4);


	/* 使能GPIO1时钟 */
	iowrite32(0xffffffff, IMX6U_CCM_CCGR1);

	/* 设置GPIO1_IO04复用为普通GPIO*/
	iowrite32(5, SW_MUX_GPIO1_IO04);
	
    /*设置GPIO属性*/
	iowrite32(0x10B0, SW_PAD_GPIO1_IO04);

	/* 设置GPIO1_IO04为输出功能 */
	iowrite32(1 << 4, GPIO1_GDIR);

	/* LED输出高电平 */
	iowrite32(1<< 4, GPIO1_DR);

	/* 创建一个kobject对象*/
	led_kobj = kobject_create_and_add("led_kobject", NULL);
	if (!led_kobj)
		return -ENOMEM;

	/* 为kobject设置属性文件*/
	retval = sysfs_create_group(led_kobj, &attr_group);
	if (retval)
		kobject_put(led_kobj);

	return retval;

	return 0;
}

static void __exit led_exit(void)
{
	/* 取消映射 */
	iounmap(IMX6U_CCM_CCGR1);
	iounmap(SW_MUX_GPIO1_IO04);
	iounmap(SW_PAD_GPIO1_IO04);
	iounmap(GPIO1_DR);
	iounmap(GPIO1_GDIR);

	/* 注销字符设备驱动 */
	kobject_put(led_kobj);
}

module_init(led_init);
module_exit(led_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("embedfire ");
MODULE_DESCRIPTION("led_module");
MODULE_ALIAS("led_module");

测试

加载完驱动模块，我们就可以通过命令进行测试

sudo sh -c "ecoh '5' >/sys/led_kobject/foo"
此时向该文件写入单字符'5'，foo_store()函数将它转化为十进制数存到全局变量中，foo_store()函数按照十进制将其打印到终端
sudo cat /sys/led_kobject/foo
执行cat命令查看foo文件内容后会打印数字5
sudo cat /sys/led_kobject/led
执行cat命令查看led文件内容后会打印数字123，与文件写入无关
sudo sh -c "ecoh 'on' >/sys/led_kobject/led"
点灯
sudo sh -c "ecoh 'off' >/sys/led_kobject/led"
灭灯

总结

通过使用驱动模型，我们就不用再手动调用mknod命令创建设备文件(节点)，本节演示并未创建/dev/目录下的设备文件，只是在/sys/目录下演示设备驱动的框架。只有调用了kobject_uevent(led_kobj, KOBJ_ADD)后，内核才会向用户空间udev/mdev守护进程发送消息，udev/mdev守护进程才会在用户空间/dev/目录下创建设备文件。
请阅读：Linux字符设备驱动详解三（使用class）