Linux驱动 2.Linux驱动之Kobject、Kset （二）（uevent mdev ktype type）

最新推荐文章于 2023-07-12 14:23:49 发布
最新推荐文章于 2023-07-12 14:23:49 发布
阅读量220 收藏 1
点赞数
分类专栏： Linux驱动
原文链接：https://blog.csdn.net/lizuobin2/article/details/51534385
版权

LDD3中说，Kobject的作用为：

  1、sysfs 表述：在 sysfs 中出现的每个对象都对应一个 kobject, 它和内核交互来创建它
  的可见表述。
  2、热插拔事件处理 ：kobject 子系统将产生的热插拔事件通知用户空间。
  3、数据结构关联：整体来看, 设备模型是一个极端复杂的数据结构，通过其间的大量链接而构
  成一个多层次的体系结构。kobject 实现了该结构并将其聚合在一起。

其中，第一条已经在前一篇文章中介绍过了，如果不了解请移驾 http://blog.csdn.net/lizuobin2/article/details/51523693

此文，将从设备总线驱动模型里的设备注册过程， device_register函数入手，分析kobject、kset 在设备这一层面的体系结构，同时主要是分析uevent机制以及 mdev 如何自动创建设备节点，实现自己想要的一些功能，比如U盘自动挂载。

整个设备的起源，应该是**/drives/base/core.c** 在这里实现了一系列函数，并导出供我们使用。

        EXPORT_SYMBOL_GPL(device_for_each_child);
        EXPORT_SYMBOL_GPL(device_find_child);

        EXPORT_SYMBOL_GPL(device_initialize);
        EXPORT_SYMBOL_GPL(device_add);
        EXPORT_SYMBOL_GPL(device_register);

        EXPORT_SYMBOL_GPL(device_del);
        EXPORT_SYMBOL_GPL(device_unregister);
        EXPORT_SYMBOL_GPL(get_device);
        EXPORT_SYMBOL_GPL(put_device);

        EXPORT_SYMBOL_GPL(device_create_file);
        EXPORT_SYMBOL_GPL(device_remove_file);

在内核 do_base_setup 初始化的过程中调用driver_init函数，间接调用device_init函数，我们先来看看device_init函数。

int __init devices_init(void)

{
          devices_kset = kset_create_and_add("devices", &device_uevent_ops, NULL);

    ……
}

创建kset 并 add 到内核里去，它的名字是devices，parent==NULL，devices_kset 对应于/sys/devices目录，device_uevent_ops后面分析。

在设备总线驱动模型中，我们要构造一个 device 结构对象，设置它所属的总线（i2c_bus_type、platform_bus_type…)，然后将它注册到内核中去，其中都避免不了调用 device_register 函数。现在我们来看 device_register

  int device_register(struct device *dev)
    {
        device_initialize(dev);
         //dev.devt = MKDEV(xxx, yyyy);  // 有些时候会提供设备的 主次设备号
        return device_add(dev);

         ......          

    }

    void device_initialize(struct device *dev)
    {
        dev->kobj.kset = devices_kset;   // 将设备的 kset 成员指向 devices_kset
        kobject_init(&dev->kobj, &device_ktype);   // 初始化 设备的 kobject 成员，并设置它的 Ktype 为 device_ktype，并没有add
        ......

    }

**kobject_init(&dev->kobj, &device_ktype)**需要注意。

 void kobject_init(struct kobject *kobj, struct kobj_type *ktype)
    {
        kobject_init_internal(kobj);
        kobj->ktype = ktype;
    }

 static struct kobj_type device_ktype = {
        .release    = device_release,
        .sysfs_ops    = &dev_sysfs_ops, // 它有必要 看一看
    };

 static struct sysfs_ops dev_sysfs_ops = {
        . show    = dev_attr_show, // 后面分析 
        .store    = dev_attr_store,
    };


 int device_add(struct device *dev)
    {

         parent = get_device(dev->parent); // 如果 dev 指定了 parent ,注意别和 dev.kobject.parent 混淆了
 setup_parent(dev, parent); // 如果 parent 不是 NULL , dev.kobject = dev.parent.kobject 
         // 将 dev 的 kobject 成员链 parent  链表,如果 dev.kobject == null , 则链入 device_keset ,也就是在 devices 目录下创建目录
         error = kobject_add(&dev->kobj, dev->kobj.parent, NULL);

          // 创建属性 dev 文件 ，后边我们会知道 cat dev 会得到设备号，供 mdev 来创建设备节点  
          if (MAJOR(dev->devt)) {
             error = device_create_file(dev, &devt_attr); // 值得一看

             error = device_create_sys_dev_entry(dev);
         }
         // 上报一个 KOBJ_ADD 事件
         kobject_uevent(&dev->kobj, KOBJ_ADD);   
    }

指定属性文件 是在 error = device_create_file(dev, &devt_attr);

int device_create_file(struct device *dev, struct device_attribute *attr)
{
    error = sysfs_create_file(&dev->kobj, &attr->attr);

}

devt_attr 定义 在 static struct device_attribute devt_attr = __ATTR(dev, S_IRUGO, show_dev, NULL);

#define __ATTR(_name,_mode,_show,_store) { \
    .attr = {.name = __stringify(_name), .mode = _mode },    \
    .show    = _show,                    \
    .store    = _store,                    \
}

将宏展开：

static struct device_attribute devt_attr = {

    .attr = {.name = __stringify(dev),.mode = S_IRUGO},   // cat dev   dev的来源
    .show    = show_dev,   // 就一行 return print_dev_t(buf, dev->devt) 返回dev的设备号         
    .store    = NULL,

}

真正的属性文件是：attr = {.name = __stringify(dev),.mode = S_IRUGO},我们在用户空间cat dev的时候调用的是Kobject->ktye->show,也就是：

static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr, char *buf)
{
    struct device_attribute *dev_attr = to_dev_attr(attr); // 转换成上边devt_attr 的结构类型
    struct device *dev = to_dev(kobj);

    if (dev_attr->show)    // 调用 show_dev 传递 主次设备号 
        ret = dev_attr->show(dev, dev_attr, buf);
}

真是大费周章~~,但是这里值得注意，dev 是内核帮我们自动创建的属性文件，根据它我们可以分析出很多东西

1、device_ktype里提供的 show store 函数 仅仅是个通用接口，我们在用户空间访问属性文件时，首先会访问这两个函数

2、show 与 store 会将 attr 转换为 device_attribute，再调用具体的 device->attr->show 或者 store 函数。

3、我们想创建自己的属性文件，就需要提供 一个deivce_attribute 结构体，在里面提供 sttr show store ，这个device_attribute 往往在 dev->type->groups 里

4、在devie_register 最后的过程中 device_add_attrs(dev) 会帮我们创建这些在 dev->type->groups里的属性

至此，我们可以发现，今后每一个创建 device ，只要你调用 device_register ,device 的 Kobject 都将链入device_kset 链表，然后通过contain_of 函数，就可以实现对 device 的访问。也就是说 kobject 往往是嵌入在其他模块中，通过Kobject、kset之前的关系，实现对更大的模块的关系管理。 也就是我们说的 Kobject 作用的第三条。

可以总结一下 device_register 上面的工作了

1、每一个 device 的kobkect都将被链入kset 链表

2、每一个 device 的kobkect 在dev.parents 目录下创建子目录（如果没有parents 就在 devices 目录下创建）

3、每一个 device 的kobkect 在它的目录下创建属性文件 dev

4、每一个 device 的kobkect 的ktype 都被设置为device_ktype，这里提供通用的show与store接口，外部访问的时候会先将attr转换为device_attr，再调用具体的device_addr->show or stror 函数

5、创建其它属性文件，依赖于 dev->type ，主要就是将 device_attribute 利用 device_creat_file 生成文件， device_attribute 里含有具体的show store函数。

6、建立dev 到 bus  class 的符号连接

现在我们来看看 kobject_uevent

int kobject_uevent(struct kobject *kobj, enum kobject_action action)
{
    return kobject_uevent_env(kobj, action, NULL);
}

int kobject_uevent_env(struct kobject *kobj, enum kobject_action action,
           char *envp_ext[])
{

     /* 如果kobject 不属于一个Kset，则向上查找到一个 属于一个kset的kobject为止 */
        top_kobj = kobj;
        while (!top_kobj->kset && top_kobj->parent)
        top_kobj = top_kobj->parent;

            kset = top_kobj->kset;    // 找到 最接近的 kset，这里就是device_kset

            uevent_ops = kset->uevent_ops;    // 获取 uevent_ops == device_uevent_ops

        // 如果 uevent_suppress 被设置 则屏蔽 uevent
        // 如果设置了 filter 则用 filter 过滤事件，稍后我们会看，只要设置了 bus 或 class 的device 都会通过

        // 调用name函数得到subsystem的名字；否则，subsystem的名字是kset中kobject的名字
        if (uevent_ops && uevent_ops->name)
            subsystem = uevent_ops->name(kset, kobj);
        else
            subsystem = kobject_name(&kset->kobj);

     /*  申请env内存 */
        env = kzalloc(sizeof(struct kobj_uevent_env), GFP_KERNEL);

    /* 获取Path 也就是kobj的路径 /sys/devices/xxx */
        devpath = kobject_get_path(kobj, GFP_KERNEL);

    /*  设置环境变量 */
        retval = add_uevent_var(env, "ACTION=%s", action_string);  // KOBJ_ADD

        retval = add_uevent_var(env, "DEVPATH=%s", devpath);  // 路径

        retval = add_uevent_var(env, "SUBSYSTEM=%s", subsystem);   // 子系统的名字

    // 如果 uevent_ops->uevent 存在则调用，显然存在，后面分析。
           if (uevent_ops && uevent_ops->uevent) {
               retval = uevent_ops->uevent(kset, kobj, env);
           }

    retval = add_uevent_var(env, "SEQNUM=%llu", (unsigned long long)seq);
           // uevent_helper[0] == /sbin/mdev     这个是通过 /etc/ini.d/rcS 指定的
           if (uevent_helper[0]) {
                char *argv [3];

                argv [0] = uevent_helper;
                argv [1] = (char *)subsystem;
                argv [2] = NULL;
                retval = add_uevent_var(env, "HOME=/");
                retval = add_uevent_var(env,"PATH=/sbin:/bin:/usr/sbin:/usr/bin");

                // 调用用户空间程序，程序名 argv[0], 并把环境变量当作参数传递过去

                retval = call_usermodehelper(argv[0], argv, env->envp, UMH_WAIT_EXEC);
           }

}

显然 uevent 的机制，就是设置环境变量，然后调用用户空间程序 mdev 进行更新设备。

上面多次使用到了device_kset->uevent_fops，是时候来看看了（并没有什么卵用）

    static struct kset_uevent_ops device_uevent_ops = {
        .filter =        dev_uevent_filter, // 只要设置了bus or class 就不会过滤
        .name =      dev_uevent_name, // 返回bus or class的name
        .uevent =    dev_uevent,  // 设置主次设备号的环境变量
    };
    // 如果设置了总线 或 类 返回1
    static int dev_uevent_filter(struct kset *kset, struct kobject *kobj)
    {
        struct kobj_type *ktype = get_ktype(kobj);

        if (ktype == &device_ktype) {
            struct device *dev = to_dev(kobj);
            if (dev->bus)
                return 1;
            if (dev->class)
                return 1;
         }
    }
    // 返回 Bus  或 类的名字
    static const char *dev_uevent_name(struct kset *kset, struct kobject *kobj)
     {
        struct device *dev = to_dev(kobj);

        if (dev->bus)
               return dev->bus->name;
        if (dev->class)
               return dev->class->name;
     }

    static int dev_uevent(struct kset *kset, struct kobject *kobj,
              struct kobj_uevent_env *env)
    {

        if (MAJOR(dev->devt)) {

            add_uevent_var(env, "MAJOR=%u", MAJOR(dev->devt));// 在环境变量中设置主次设备号
            add_uevent_var(env, "MINOR=%u", MINOR(dev->devt)); // 然而mdev并不是从这里读取的
            name = device_get_devnode(dev, &mode, &tmp);
            if (name) {
                add_uevent_var(env, "DEVNAME=%s", name);
            if (mode)
                add_uevent_var(env, "DEVMODE=%#o", mode & 0777);
        }
    }

    error = device_add_class_symlinks(dev); // 创建到 类 的符号连接

    error = device_add_attrs(dev); // 根据dev->type里提供的device_attribute信息，创建其它的属性文件

    error = bus_add_device(dev); // 创建到 bus 的符号链接

    return retval;

}

kobject_uevent的工作

1、将 device 的 kobject 的PATH 、name、主次设备号等等设置到环境变量nev->nevp里

2、调用用户空间 mdev

mdev 是啥，mdev 可以说是udev的精简版，在 busybox 制作文件系统的时候被编译进去，它主要的工作就是根据/sys 目录的信息来帮助我们自动创建设备节点，更详细的概念请自行百度。向要搞清，mdev 创建设备几点的过程，那只能看Busybox的源码了。。

附上一个我做实验时打印出来的环境变量

   env[0] ACTION=add
   env[1] DEVPATH=/devices/platform/myled
   env[2] SUBSYSTEM=platform
   env[3] MAJOR=251
   env[4] MINOR=0
   env[5] DEVNAME=myled
   env[6] MODALIAS=platform:myled
   env[7] SEQNUM=642
   env[8] HOME=/
   env[9] PATH=/sbin:/bin:/usr/sbin:/usr/bin

现在我们来看看，从内核空间调用的这个用户程序mdev

int mdev_main(int argc, char **argv)
{
// mdev -s 开机扫描/sys 目录创建设备节点，这里不分析
if (argc == 2 && !strcmp(argv[1],"-s")) {
…
} else {
action = getenv(“ACTION”); // 获得action 就是add or remove
env_path = getenv(“DEVPATH”); // 获得DEVPATH
if (!action || !env_path)
bb_show_usage();

    sprintf(temp, "/sys%s", env_path);   // /sys+DEVPATH 比如/sys/devices/xxx
    if (!strcmp(action, "remove"))  // 移除 dev
        make_device(temp, 1);
    else if (!strcmp(action, "add")) { // 增加 dev
        make_device(temp, 0);
    }
}

}

static void make_device(char *path, int delete)
{
// 获取主次设备号，看看是如何获取的
if (!delete) {
// 在path 后边 + “/dev” 那么path == /sys/devices/xxx/dev
strcat(path, “/dev”);
len = open_read_close(path, temp + 1, 64); //读dev 我们前边说过了，这里会调用show 传递主次设备号~
*temp++ = 0;
if (len < 1) return;
}

// 获得设备名字，根据最后一个"/"
device_name = bb_basename(path);

// 根据 path 的第五个字符来判断设备类型，如果是在/sys/class 目录的话 就是字符设备，其他的都是块设备
type = path[5]=='c' ? S_IFCHR : S_IFBLK;

// 如果 /etc/mdev.conf 有这个配置文件的话，根据配置文件的规则来 创建设备节点 并执行一些命令
if (ENABLE_FEATURE_MDEV_CONF) {
    // 这个不如直接来看 mdev.conf 来得实在
    fd = open("/etc/mdev.conf", O_RDONLY);
    ......
}

if (!delete) {
    if (sscanf(temp, "%d:%d", &major, &minor) != 2) return;
    // mknod 创建设备节点
    if (mknod(device_name, mode | type, makedev(major, minor)) && errno != EEXIST)
        bb_perror_msg_and_die("mknod %s", device_name);

}

}

关于 /etc/mdev.conf 真是太有用处了 ，附上韦东山老师 uevent 的文档，我就不卖弄了。

我接上U盘，想自动挂载，怎么办？
	mdev.conf的格式：
	<device regex> <uid>:<gid> <octal permissions> [<@|$|*> <command>]
 
	device regex：正则表达式，表示哪一个设备
	uid: owner
	gid: 组ID
	octal permissions：以八进制表示的属性
	@：创建设备节点之后执行命令
	$：删除设备节点之前执行命令
	*: 创建设备节点之后 和 删除设备节点之前 执行命令
	command：要执行的命令
<span style="white-space:pre">	// 韦东山老师写了个驱动，有 led led1 led2 led3 这四个设备</span>
	写mdev.conf
	1.
		leds 0:0 777
		led1 0:0 777
		led2 0:0 777
		led3 0:0 777
 
	2.
		leds?[123]? 0:0 777
 
	3.
		leds?[123]? 0:0 777 @ echo create /dev/$MDEV > /dev/console
 
	4.
		leds?[123]? 0:0 777 * if [ $ACTION = "add" ]; then echo create /dev/$MDEV > /dev/console; else echo remove /dev/$MDEV > /dev/console; fi
 
	5. 
		leds?[123]? 0:0 777 * /bin/add_remove_led.sh
 
	把命令写入一个脚本：
		add_remove_led.sh
 
		#!/bin/sh
		if [ $ACTION = "add" ]; 
		then 
			echo create /dev/$MDEV > /dev/console; 
		else 
			echo remove /dev/$MDEV > /dev/console; 
		fi
 
	6. U盘自动加载
		sda[1-9]+ 0:0 777 * if [ $ACTION = "add" ]; then mount /dev/$MDEV /mnt; else umount /mnt; fi
 
	7.
		sda[1-9]+ 0:0 777 * /bin/add_remove_udisk.sh
 
		add_remove_udisk.sh
		#!/bin/sh
		if [ $ACTION = "add" ]; 
		then 
			mount /dev/$MDEV /mnt; 
		else 
			umount /mnt; 
		fi

附上一个 我做实验的代码，仅供参考，基于Linux2.6.32.2内核

1、平台总线设备，它的父设备是 platform_bus，按照我们的推测，它应该在出现在 /sys/devices/platform/ 目录下

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/fs.h>
#include <linux/init.h>
#include <linux/device.h>
#include <linux/interrupt.h>
#include <linux/sched.h> 
#include <linux/irq.h>
#include <asm/uaccess.h>
#include <linux/input.h>
#include <linux/platform_device.h>
// 设备资源
static struct resource led_resource[] = {	//jz2440的参数，驱动未测试 
	[0] = {
		.start = 0x56000010,
		.end   = 0x56000010 + 8 - 1,
		.flags = IORESOURCE_MEM,
	},
	[1] = {
		.start = 5,
		.end   = 5,
		.flags = IORESOURCE_IRQ,
	},
};
 
static void led_release(struct device *dev){
 
}
 
// 创建一个设备
static struct platform_device led_dev = {
	.name = "myled",	//设备名字 与 驱动相匹配
	.id	  = -1,
	.num_resources = ARRAY_SIZE(led_resource),
	.resource = led_resource,
	
	.dev = {
		.release = led_release,
		.devt = MKDEV(252, 1),
	},
};
 
static int led_dev_init(void){
 
	//向bus注册led_dev match drv链表进行配对
	platform_device_register(&led_dev);
	return 0;
}
 
static void led_dev_exit(void){
	platform_device_unregister(&led_dev);
}
 
module_init(led_dev_init);
module_exit(led_dev_exit);
MODULE_LICENSE("GPL");
	

打印出来的环境变量：
env[0] ACTION=add
env[1] DEVPATH=/devices/platform/myled
env[2] SUBSYSTEM=platform
env[3] MAJOR=251
env[4] MINOR=0
env[5] DEVNAME=myled
env[6] MODALIAS=platform:myled
env[7] SEQNUM=642
env[8] HOME=/
env[9] PATH=/sbin:/bin:/usr/sbin:/usr/bin

在这里插入图片描述
在这里插入图片描述
我们创建了 dev 并设置它的主次设备号，mdev 就自动为我们创建设备节点了~

2、什么都不依赖的单纯设备，它的父设备是NULL，按照我们的推测，它应该在出现在 /sys/devices/目录下

/*
 *	MINI2440 GPB5~8为LED引脚
 */
 
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/fs.h>
#include <linux/init.h>
#include <linux/delay.h>
#include <asm/uaccess.h>
#include <asm/irq.h>
#include <asm/io.h>
#include <mach/regs-gpio.h>
#include <mach/hardware.h>
#include <linux/device.h>
 
static int first_drv_open(struct inode *inode, struct file *file)
{
	return 0;
}
 
static ssize_t first_drv_write(struct file *file, const char __user *buf, size_t count, loff_t * ppos)
{
	return 0;
}
 
static struct file_operations first_drv_fops = {
    .owner  =   THIS_MODULE,    /* 这是一个宏，推向编译模块时自动创建的__this_module变量 */
    .open   =   first_drv_open,     
	.write	=	first_drv_write,	   
};
 
int major;
static int first_drv_init(void)
{
	major = register_chrdev(0, "first", &first_drv_fops);
	struct device dev = {
		.init_name = "my_first_drv",
		.devt = MKDEV(major, 0),
	};
	device_register(&dev);
 
	return 0;
}
 
static void first_drv_exit(void)
{
	unregister_chrdev(major, "first_drv"); // 卸载
 
	iounmap(gpbcon);
}
 
module_init(first_drv_init);
module_exit(first_drv_exit);
MODULE_LICENSE("GPL");

在这里插入图片描述
最后，我们再来回顾一下整个流程~

kobject:

    1、每一个 device 的kobkect都将被链入kset 链表

    2、每一个 device 的kobkect 在 device.kobj.parent 目录下创建子目录

    3、每一个 device 的kobkect 在它的目录下创建属性文件 dev

    4、每一个 device 的kobkect 的ktype 都被设置为device_ktype，通过 show 可以访问到device的主次设备号

uevent:

    5、将 device 的 kobject 的PATH 、name、主次设备号等等设置到环境变量nev->nevp里

    6、调用用户空间 mdev
    
mdev:
    7、读取环境变量，创建设备节点~

至此，我们应该对kobject的作用有了一个全面的了解。写的不好，还请多批评指正。

StevenYang2008
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Linux设备模型kobj_type、kobject、kset三者间关系总结
08-20
Linux 设备模型 kobj_type、kobject、kset 三者间关系总结 Linux 设备模型中，kobj_type、kobject、kset 三者之间存在着复杂的关系。为了更好地理解这三者的关系，我们需要从基本概念开始，逐步深入到流程图的解释...
linux kobject kset bus.tar.gz
09-14
本压缩包`linux kobject kset bus.tar.gz`包含了基于`kobject`和`kset`实现的自定义总线驱动的源码和测试代码。 首先，我们来了解一下`kobject`。`kobject`是Linux内核中表示对象的基本数据结构，可以代表任何内核...
linux驱动模型之kobject kset
风雨无阻
08-28 659
分析kobject，及相关的ktype和kset。
linux设备驱动模型之Kobject、kobj_type、kset
lxllinux的博客
11-19 634
一、sysfs文件系统简介： 1、sysfs概述 sysfs文件系统是内核对象（kobject）、属性（kobj_type）、及它们相互关系的一种表现。 sysfs非常重要的特征：用户可以从sysfs中读出内核数据，也可以将用户数据写入内核。 2、内核结构与sysfs对应关系： kobject    --&gt;目录 kobj_type--&gt;属性文件 3、特点 sysfs文件系统...
设备驱动基础0:设备模型之kobject,kset及其关系
xiongjiao0610的专栏
03-01 3136
Linux2.6以后的设备驱动，都是在设备模型的基础上构建的，因此，要编写linux下的设备驱动程序，不论是usb设备，pci设备等， 都需要了解设备模型。 设备模型的基础结构体主要是kobject，kset这两个结构体： struct kobject {    char      * k_name;    char      name[KOBJ_NAME_LEN];
linux内核之kobject与kset
qq_39048131的博客
11-23 434
kobject数据结构 struct kobject { const char *name;//对象的文本名称,可利用sysfs导出到用户空间. struct list_head entry;//标准的链表元素,可将多个kobject放到一个链表中. struct kobject *parent;//父对象指针,可建立kobject的层次关系. struct kset *kset;//将对象与其他对象放置到一个集合时,需要kset struct kobj_type *ktype;//属性,名
struct kset_uevent_ops
zdh_12的专栏
07-29 1102
include/linux/kobject.h struct kset_uevent_ops {     int (* const filter)(struct kset *kset, struct kobject *kobj);     const char *(* const name)(struct kset *kset, struct kobject *kobj);     i
HOWTO-linux.rar_linux 驱动
09-14
在Linux系统中，驱动程序是操作系统与硬件设备之间的桥梁，它们负责向内核提供与特定硬件设备交互的接口。"HOWTO-linux.rar_linux 驱动"这个压缩包可能包含了关于Linux驱动开发的重要资料，包括指南、教程或者代码...
STM32MP135实现异步通知【支持STM32MP1系列单片机_Linux驱动】.zip
04-28
对于STM32MP135，可能需要编写GPIO驱动、串口驱动、I2C驱动、SPI驱动等，以便与芯片的外设进行交互。 1. GPIO驱动：STM32MP135拥有丰富的GPIO端口，可以作为输入或输出。驱动需要实现设置GPIO状态、读取GPIO状态、...
Linux设备模型kobject与kset之间的关系
08-20
kset_register主要实现了两步操作，一是调用kobject_add_internal增加父目录的引用计数、创建sysfs文件系统下的目录和属性文件等，二是处理kobject_uevent事件。kobject_uevent事件处理函数调用了kobject_uevent_env...
linux设备驱动模型
12-21
linux设备驱动模型 1、kobject原理与实例分析 2、kset原理与实例分析 3、bus（总线）原理与实例分析 4、device（设备）原理与实例分析 5、driver（驱动）原理与实例分析
kset与热插拔中的uevent和call_usermodehelper
weixin_52849254的博客
12-05 722
kset可以认为是一组kobject的集合，是kobject的容器。kset本身也是一个内核对象，所以需要内嵌一个kobject对象。其完整定义如下： struct_kset_uevent_ops类型声明如下： kset上的一些主要操作有： kset_register 用来初始化并向系统注册一个kset对象，函数的实现如下： 其中kset_init和koadd_intemal的功能都比较直观，分别用来初始化kset对象和向系统注册该kset对象，因为kset对象本身就是一个由kobject代表的内核对
Linux驱动之Kobject、Kset （二）uevent mdev ktype type
muyiyunfan的博客
11-30 210
LDD3中说，Kobject的作用为：     1、sysfs 表述：在 sysfs 中出现的每个对象都对应一个 kobject, 它和内核交互来创建它的可见表述。     2、热插拔事件处理 ：kobject 子系统将产生的热插拔事件通知用户空间。     3、数据结构关联：整体来看, 设备模型是一个极端复杂的数据结构，通过其间的大量链接...
【Linux kernel】Linux设备模型(3)_Uevent
weixin_41028159的博客
12-02 385
Uevent是Kobject的一部分，用于在Kobject状态发生改变时，例如增加、移除等，通知用户空间程序。用户空间程序收到这样的事件后，会做相应的处理。该机制通常是用来支持热拔插设备的，例如U盘插入后，USB相关的驱动软件会动态创建用于表示该U盘的device结构（相应的也包括其中的kobject），并告知用户空间程序，为该U盘动态的创建/dev/目录下的设备节点，更进一步，可以通知其它的应用程序，将该U盘设备mount到系统中，从而动态的支持该设备。
Linux设备模型(3)_Uevent
Linux内核研究
03-26 1177
1. Uevent的功能 Uevent是Kobject的一部分，用于在Kobject状态发生改变时，例如增加、移除等，通知用户空间程序。用户空间程序收到这样的事件后，会做相应的处理。 该机制通常是用来支持热拔插设备的，例如U盘插入后，USB相关的驱动软件会动态创建用于表示该U盘的device结构（相应的也包括其中的kobject），并告知用户空间程序，为该U盘动态的创建/dev/目录下
七种Linux设备驱动模型之——Kset
最新发布
m0_74282605的博客
07-12 188
接着上面的分析，看kernel_add_sysfs_param此函数，在此函数中通过locate_module_kobject函数建立起与kset（module_kset）之间的联系。当其中的kobject对象的状态发生变化需要通知用户空间的时候，就需要调用uevent_ops中的函数。可以看到通过kset_create_and_add创建一个名字为"module"的kset。最终会在/sys/module下的任何一个模块，都会有一个名字为"parameters"的目录。带着此问题继续看代码。
uevent 驱动_uevent分析（和设备驱动有关）
weixin_29514317的博客
02-11 317
1．kobject, ktype, ksetkobject代表sysfs中的目录。ktype代表kobject的类型，主要包含release函数和attr的读写函数。比如，所有的bus都有同一个bus_type；所有的class都有同一个class_type。kset包含了subsystem概念，kset本身也是一个kobject，所以里面包含了一个kobject对象。另外，kset中包含kset...
LINUX设备驱动之设备模型二--kset
GangsterPan的专栏
03-27 814
我们已经知道了kset内嵌了kobject来表示自身的节点，创建kset就要完成其内嵌kobject，注册kset时会产生一个事件，事件而最终会调用uevent_ops字段指向结构中的函数，这个事件是通过用户空间的hotplug程序处理。下面我们一步一步分析。 内核同样提供了创建和注册kset的函数kset_create_and_add() struct kset *kset_create_a
linux glib2/gio + udisks2 库处理移动设备重命名
qq_943588990的博客
10-09 1064
linux 系统给移动设备重命名 linux C语言设置U盘卷标 glib2/udisks2 API简单使用案例
Linux设备驱动深度解析：权威指南与实战教程
书中详细介绍了设备驱动程序的基础概念，包括设备和驱动程序的工作原理、中断处理流程、Linux设备模型、udev、sysfs和kobject的使用，以及热插拔、电源管理和微码下载等。对于字符设备和串行设备，提供了具体的例子...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值