设备模型三（潜谈sysfs）

1. 前言
   引出一个问题：假设 /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树，我们来看看如何形成的，其实如果看了前面介绍的VFS的理解这篇文章,理解sysfs的挂载应该比较轻松
   
   sysfs_init中

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

很明显,根据代码, 注册完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树创建完毕

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

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

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

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

讲到这里,个人认为基本上很清晰了,说来也奇怪, sysfs居然在open的时候才生成inode, 为什么这个设计不清楚啊，如果有谁知道请告知一下,万分感谢,不过想想有一点可以确认的是,这么作似乎在节省inode缓存空间的使用, 意图在用的时候生成inode,假设如果sysfs在创建文件的时候生成inode,那它所生成的inode基本上不会iput（释放掉，从而让出inode空间）…，而像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还是没什么赶脚,没关系,带着问题继续往下看