很明显,根据代码, 注册完sysfs_fs_type文件系统后,紧接着挂载
static struct file_system_type sysfs_fs_type = { .name = "sysfs", .mount = sysfs_mount, //挂载函数 .kill_sb = sysfs_kill_sb, };kern_mount函数会调用sysfs_mount函数 完成挂载后sysfs_dirent, inode, dentry三者关系 就是说,我们的sysfs的VFS树创建完毕
接下来讨论sysfs_create_file函数 流程下图所示: sysfs_create_file(b的kobj, attr, “xx”)创建完之后, 仅仅是在sysfs的目录结构上建立了关系,但是并没有生成inode, 这个就很奇怪了啊,跟ext3的套路不一样我去,没关系,我们慢慢看, 我们可以看到sysfs_direct的对应关系(/sys/a/b/xx)如下图: 至此,创建文件就这样了
sysfs的读写操作 话说本以为sysfs的读写操作跟其他VFS差不多,就是找dentry，获取inode,比如ext3文件系统,我在创建文件的时候inode已经生成了，但是sysfs不同, 通过调用sysfs_create_file之后,并没有生成indoe, 那什么时候生成inode呢？ 是在打开文件的时候生成的inode.. 对于文件的打开操作,在VFS的一文的讨论中并没有说明,接下来需讨论一下（依旧跟据上面的例子继续分析），看下图为当前的目录情况 当调用open函数时,调用关系如下图 上图给出了open的调用关系链，接下来看看inode, dentry, sysfs_direct 在open过程中的情况 讲到这里,个人认为基本上很清晰了,说来也奇怪, sysfs居然在open的时候才生成inode, 为什么这个设计不清楚啊，如果有谁知道请告知一下,万分感谢,不过想想有一点可以确认的是,这么作似乎在节省inode缓存空间的使用, 意图在用的时候生成inode,假设如果sysfs在创建文件的时候生成inode,那它所生成的inode基本上不会iput..，而像ext3这样的文件系统,基本上生成的文件（inode）,写完就close了,close的时就iput了,所以.. 之后调用完sysfs_lookup函数后, 调用__dentry_open函数，最后调用sysfs_open_file函数(VFS惯用伎俩)，补充啰嗦一句, xx是文件类型(非目录)，所以.open调用的是sysfs_open_file
static int sysfs_open_file(struct inode *inode, struct file *file) { struct sysfs_dirent *attr_sd = file->f_path.dentry->d_fsdata; //大家可以看到这里的 attr_sd 就是 xx的sysfs_direct struct kobject *kobj = attr_sd->s_parent->s_dir.kobj;//这里attr->sd_sparent是a的sd，这里获取的kobj是a的kobj，关于s_dir.kobj的赋值可以参考前一篇文章 struct sysfs_buffer *buffer; const struct sysfs_ops *ops; int error = -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 = kobj->ktype->sysfs_ops; //将a的ktype赋值给ops else { WARN(1, KERN_ERR "missing sysfs attribute operations for " "kobject: %s\n", kobject_name(kobj)); goto err_out; }接着来
buffer = kzalloc(sizeof(struct sysfs_buffer), GFP_KERNEL); //生成了一个buffer if (!buffer) goto err_out; mutex_init(&buffer->mutex); buffer->needs_read_fill = 1; buffer->ops = ops; //将ops扔进buffer中 file->private_data = buffer; //将buffer扔进file->private_data这样open函数后, 在进行read或者write, 直接file->private_data->ops就可以了,如下图所示
其实就是操作xx,就是调用了a的ktype 总结: 此篇的讨论结束了,讨论了sysfs的挂载，以及读写脉络,最后贴出一张经典图 如上图sysfs超级块sysfs_sb、dentry根目录root、sysfs_direct根目录sysfs_root都是在sysfs初始化时创建。 sysfs_root下的子节点是添加设备对象或对象属性时调用sysfs_create_dir/ sysfs_create_file创建的，同时会申请对应的inode的索引号s_ino。注意此时并未创建inode。 inode是在用到的时候调用sysfs_get_inode函数创建并依据sysfs_sb地址和申请到的s_ino索引计算散列表位置放入其中。 dentry的子节点也是需要用的时候才会创建。比如open文件时，会调用path_walk根据路径一层层的查找指定dentry，如果找不到，则创建一个，并调用父dentry的inode的lookup函数（sysfs文件系统的为sysfs_lookup）查找对应的子inode填充指定的dentry。 说道这里大家可能对ktype还是没什么赶脚,没关系,带着问题继续往下看
