设备模型三（潜谈sysfs）

1. 前言
   引出一个问题&＃xff1a;假设 /sys/a/xx, xx是kobj a的属性文件, 当对xx进行写操作时,即echo ‘1’ > /sys/a/xx
   实际上,调用了kobj a的ktype中定义的接口函数, 这一系列的流程涉及到
   1.属性文件的创建函数 sysfs_create_file
   2.sysfs的挂载
   3.sysfs的读写操作
   下面就围绕上面三点展开讨论
2. sysfs的挂载
   系统初始化时期已经将sysfs挂载上了形成了一颗独立的VFS树&＃xff0c;我们来看看如何形成的&＃xff0c;其实如果看了前面介绍的VFS的理解这篇文章,理解sysfs的挂载应该比较轻松
   
   sysfs_init中

err &＃61; register_filesystem(&sysfs_fs_type);//注册文件系统if (!err) {sysfs_mnt &＃61; kern_mount(&sysfs_fs_type);//挂载if (IS_ERR(sysfs_mnt)) {printk(KERN_ERR "sysfs: could not mount!\n");err &＃61; PTR_ERR(sysfs_mnt);sysfs_mnt &＃61; NULL;unregister_filesystem(&sysfs_fs_type);goto out_err;}}


很明显,根据代码, 注册完sysfs_fs_type文件系统后,紧接着挂载

static struct file_system_type sysfs_fs_type &＃61; {.name &＃61; "sysfs",.mount &＃61; sysfs_mount, //挂载函数.kill_sb &＃61; sysfs_kill_sb,
};


kern_mount函数会调用sysfs_mount函数

完成挂载后sysfs_dirent, inode, dentry三者关系

就是说,我们的sysfs的VFS树创建完毕

1. 接下来讨论sysfs_create_file函数
   流程下图所示:
   
   sysfs_create_file(a的kobj, attr, “xx”)创建完之后&＃xff08;注意&＃xff0c;属性文件xx虽然是个文件&＃xff0c;但在sysfs中也有对应的目录项&＃xff0c;只不过此目录项不是文件夹属性&＃xff0c;即&＃xff1a;如果是文件夹的情况&＃xff0c;比如 kobj_create_and_add函数&＃xff0c;函数内部生成文件夹目录项调用的是&＃xff1a;sd &＃61; sysfs_new_dirent(name, mode, SYSFS_DIR);&＃xff0c;而sysfs_create_file函数内部生成属性文件目录项则是 sd &＃61; sysfs_new_dirent(name, mode, SYSFS_KOBJ_ATTR);&＃xff09;, 仅仅是在sysfs的目录结构上建立了关系,但是并没有生成inode, 这个就很奇怪了啊,跟ext3的套路不一样我去,没关系,我们慢慢看, 我们可以看到sysfs_direct的对应关系(/sys/a/xx)如下图:
   
   至此,创建文件就这样了

2. sysfs的读写操作
   话说本以为sysfs的读写操作跟其他VFS差不多,就是找dentry&＃xff0c;获取inode,比如ext3文件系统,我在创建文件的时候inode已经生成了&＃xff0c;但是sysfs不同, 通过调用sysfs_create_file之后,并没有生成indoe, 那什么时候生成inode呢&＃xff1f; 是在打开文件的时候生成的inode…
   对于文件的打开操作,在VFS的一文的讨论中并没有说明,接下来需讨论一下&＃xff08;依旧跟据上面的例子继续分析&＃xff09;&＃xff0c;看下图为当前的目录情况
   
   当调用open函数时,调用关系如下图
   
   这里补充一下&＃xff1a;
   sysfs_dir_inode_operations 中 有sysfs_lookup函数&＃xff0c;此函数首先&＃xff1a;
   ①通过 a的目录项寻找 xx的目录项 &＃xff08;通过上面的 sys_create_file已创建&＃xff09;。
   ②生成一个新的 inode&＃xff0c;并初始化&＃xff0c;与传入进来的 dentry(xx的&＃xff09;建立关系。dentry->d_inode &＃61; inode;
   ③xx的inode与目录项目建立关系&＃xff1a;dentry->d_fsdata &＃61; sd(xx的目录项sysfs_dirent)

上图给出了open的调用关系链&＃xff0c;接下来看看inode, dentry, sysfs_direct 在open过程中的情况

关于步骤1&＃xff0c;在补充解释一下&＃xff1a;
如果再 /sys 上建立目录&＃xff0c;但是没被打开&＃xff0c;即、/sys/a/xx
则open&＃xff08;/sys/a/xx&＃xff09;后&＃xff0c;
①通过dentry(/sys)找 a的dentry&＃xff0c;发现没找到
②新建立 dentry(a), 调用 sysfs_lookup 建立 a的inode&＃xff0c;a的目录项&＃xff0c;a的dentry三者关系&＃xff0c;
③在回到 步骤1 &＃xff08;goto retry&＃xff09;&＃xff0c;以同样的方法&＃xff0c;处理xx文件

讲到这里,个人认为基本上很清晰了,说来也奇怪, sysfs居然在open的时候才生成inode, 为什么这个设计不清楚啊&＃xff0c;如果有谁知道请告知一下,万分感谢,不过想想有一点可以确认的是,这么作似乎在节省inode缓存空间的使用, 意图在用的时候生成inode,假设如果sysfs在创建文件的时候生成inode,那它所生成的inode基本上不会iput&＃xff08;释放掉&＃xff0c;从而让出inode空间&＃xff09;…&＃xff0c;而像ext3这样的文件系统,基本上生成的文件&＃xff08;inode&＃xff09;,写完就close了,close的时就iput了,所以…
之后调用完sysfs_lookup函数后, 调用__dentry_open函数&＃xff0c;最后调用sysfs_open_file函数(VFS惯用伎俩)&＃xff0c;补充啰嗦一句, xx是文件类型(非目录)&＃xff0c;所以.open调用的是sysfs_open_file

static int sysfs_open_file(struct inode *inode, struct file *file)
{struct sysfs_dirent *attr_sd &＃61; file->f_path.dentry->d_fsdata; //大家可以看到这里的 attr_sd 就是 xx的sysfs_directstruct kobject *kobj &＃61; attr_sd->s_parent->s_dir.kobj;//这里attr->sd_sparent是a的sd&＃xff0c;这里获取的kobj是a的kobj&＃xff0c;关于s_dir.kobj的赋值可以参考前一篇文章struct sysfs_buffer *buffer;const struct sysfs_ops *ops;int error &＃61; -EACCES;/* need attr_sd for attr and ops, its parent for kobj */if (!sysfs_get_active(attr_sd))return -ENODEV;/* every kobject with an attribute needs a ktype assigned */if (kobj->ktype && kobj->ktype->sysfs_ops)ops &＃61; kobj->ktype->sysfs_ops; //将a的ktype赋值给opselse {WARN(1, KERN_ERR "missing sysfs attribute operations for ""kobject: %s\n", kobject_name(kobj));goto err_out;}


接着来

buffer &＃61; kzalloc(sizeof(struct sysfs_buffer), GFP_KERNEL); //生成了一个bufferif (!buffer)goto err_out;mutex_init(&buffer->mutex);buffer->needs_read_fill &＃61; 1;buffer->ops &＃61; ops; //将ops扔进buffer中file->private_data &＃61; buffer; //将buffer扔进file->private_data


这样open函数后, 在进行read或者write, 直接file->private_data->ops就可以了,如下图所示

其实就是操作xx,就是调用了a的ktype
总结:
此篇的讨论结束了,讨论了sysfs的挂载&＃xff0c;以及读写脉络,最后贴出一张经典图

如上图sysfs超级块sysfs_sb、dentry根目录root、sysfs_direct根目录sysfs_root都是在sysfs初始化时创建。
sysfs_root下的子节点是添加设备对象或对象属性时调用sysfs_create_dir/ sysfs_create_file创建的&＃xff0c;同时会申请对应的inode的索引号s_ino。注意此时并未创建inode。
inode是在用到的时候调用sysfs_get_inode函数创建并依据sysfs_sb地址和申请到的s_ino索引计算散列表位置放入其中。
dentry的子节点也是需要用的时候才会创建。比如open文件时&＃xff0c;会调用path_walk根据路径一层层的查找指定dentry&＃xff0c;如果找不到&＃xff0c;则创建一个&＃xff0c;并调用父dentry的inode的lookup函数&＃xff08;sysfs文件系统的为sysfs_lookup&＃xff09;查找对应的子inode填充指定的dentry。
说道这里大家可能对ktype还是没什么赶脚,没关系,带着问题继续往下看