蜗窝科技

文中介绍的比较清楚，用户对kernel空间特定数据属性访问是通过sysfs来实现，具体形式为读写设备文件属性。文中对calss.c进行分析说明但对device driver实现kobj->ktype->sysfs_ops->show调用逻辑理解不是特别清楚； 结合kernel driver的实现补充，进一步理解其调用关系； 调用栈：user（read(dev_file)）->syscall(read)->vfs(file_operations.read)->sysfs(sysfs_file_operation.read->fill_read_buffer->sysfs_ops.show)->driver(xxx_sysfs_ops.show) 1.vfs提供统一文件操作接口，sysfs需要实现vfs文件操作结构file_operations,即sysfs_file_operations; 2.sysfs_file_operations中sysfs file相关操作接口,负责sysfs文件及其属性的打开、读、写等 /* const struct file_operations sysfs_file_operations = { .read = sysfs_read_file, .write = sysfs_write_file, .llseek = generic_file_llseek, .open = sysfs_open_file, .release = sysfs_release, .poll = sysfs_poll, }; */ 4.对于“每一个Kobject，都会对应sysfs中的一个目录”，说明sysfs_ops通过kobject与device driver关联； 5.“该变量以sysfs attribute的形式开放出来”：通过sysfs接口开放attribute给用户，用户设置atrribute来控制driver函数调用或功能 6..sysfs_ops中相关函数怎么关联至driver中sysfs_ops实现呢？ 通过kobj对象来关联具体device driver： sysfs_read_file->fill_read_buffer.sysfs_ops.ops->show(kobj,attr_sd->s_attr.attr, buffer->page)->driver.show() 对dma中sysfs_ops回调函数的实现如下： （linux/v2.6.39.4/source/fs/sysfs/inode.c#L269） sys_file_operations：主要用户操作sysfs_kobj_attr; ```C ///linux/v2.6.39.4/source/drivers/dma/ioat/dma.c#L1142 const struct sysfs_ops ioat_sysfs_ops = { .show = ioat_attr_show, }; //sysfs_ops回调dma的ioat_attr_show，具体实现功能由dma driver负责。 static ssize_t ioat_attr_show(struct kobject *kobj, struct attribute *attr, char *page) { struct ioat_sysfs_entry *entry; struct ioat_chan_common *chan; entry = container_of(attr, struct ioat_sysfs_entry, attr); chan = container_of(kobj, struct ioat_chan_common, kobj); if (!entry->show) return -EIO; return entry->show(&chan->common, page); } ```

博主，可以问一下，你的这个图使用什么软件去画的呢，感觉很方便的样子。

支持大佬！

@wowo 昵称被限制，要换个马甲，ip被限制咋办呢，总不能再换设备吧

1.个人理解kset_uevent_ops的逻辑和vfs中struct file_operations {}结构很类似（linux/v2.6.39.4/source/include/linux/fs.h#L1537）； 2.用户只需读写设备文件，不用关心底层设备驱动，通过文件系统vfs的标准接口调用设备文件对应device来调用具体的设备驱动程序实现。 3.用户空间对读device的调用逻辑： usr->syscall(read)->file_operations.read()->driver.read_impl(); 4.对于kset_uevent_ops{}，文中说了filter、name、event便于内核同一管理。 对于回调函数filter等接口，不同device需要在自己回调函数中实现具体功能，如（linux/v2.6.39.4/source/drivers/base/bus.c#L157）（linux/v2.6.39.4/source/fs/gfs2/sys.c#L630） （linux/v2.6.39.4/source/mm/slub.c#L4674） 即内核提供像file_operations{}类似的标准接口，不同device或sys需要实现kset_uevent_ops{}中回调函数具体功能。

@devin：1.动态创建：在内核空间动态分配内存。 2.而不能静态定义或者位于堆栈之上：静态变量区、堆、栈是用户空间，用户空间分配内存需用通过C库或系统调用分配内存，实际上，用户空间分配的物理内存需通过内核来分配；

kobject,内核基础设施，怎么和device（抽象设备）关联？怎么和driver关联？内核怎么通过kobject调用到对应的device？ 1. kobject会设备文件的形式在“sys”下出现，ket是kobject的集合，会将相似的kobj集合起来，在sys下也会以设备文件形式显示。 2.ktype包含kobj数据结构中属性的集合，有释放kobject数据结构内存占用接口release。 3.每个包含kobject结构，如bus、device、devie_driver都需实现ktype,并实现其回调函数release，而sysfs_ops相关操作必须通过ktype中接口中转。因为sysfs看到是kobject对应的设备文件，真正操作文件的主体是包含kobj结构的上层数据结构，它才知道什么时候释放和操作设备文件，并调用kobj中ktype相关接口实现释放内存和调用文件接口。 4. syscall->sysfs->fs_ops->callback->kobject->device

@bsp：大佬讲的好详细呀

@红桃JK：捉

@阿布：内核中io.h里使用dsb 定义了 io barriers。内核源码里的其他地方也有使用dsb 的，但有些地方的使用感觉有些不太好，比如android7.1 内核(msm-3.18)里 app_setting.c 75行中的mb()，其实完全可以使用smp_mb()，对吗？