读Kernel的一枚小发现

[nossiac]

今天抽空读了一会linux内核，在VFS的代码里，发现这样的一段代码：

//代码位于 linux/fs/filesystem.c

//.....

int register_filesystem(struct file_system_type * fs)
{
	int res = 0;
	struct file_system_type ** p;

	BUG_ON(strchr(fs- >name, '.'));
	if (fs- >next)
		return -EBUSY;
	INIT_LIST_HEAD(&fs- >fs_supers);
	write_lock(&file_systems_lock);
	p = find_filesystem(fs- >name, strlen(fs- >name));
	if (*p)
		res = -EBUSY;
	else
		*p = fs;
	write_unlock(&file_systems_lock);
	return res;
}

//.....

static struct file_system_type **find_filesystem(const char *name, unsigned len)
{
	struct file_system_type **p;
	for (p=&file_systems; *p; p=&(*p)->next)
		if (strlen((*p)->name) == len &&
		    strncmp((*p)->name, name, len) == 0)
			break;
	return p;
}

我好奇的是，代码中使用了指向指针的指针。从功能上说，直接使用指针也能完成同样的任务。如下：

static struct file_system_type *find_filesystem(const char *name, unsigned len)
{
	struct file_system_type *p;
	for (p=file_systems; p; p=p->next)
		if (strlen(p->name) == len &&
		    strncmp(p->name, name, len) == 0)
			break;
	return p;
}

当然，相应的，我们也要修改register_filesystem的实现。

原代码中为什么特别地选择“struct file_system_type **p; ”这种方式呢？

我猜测：

一、操作链表的一点点便利。从register_filesystem的源代码可以看出，注册时只需给返回的指针赋值就OK。而直接返回指针的话，则还需要一步修改链表的动作。

二、如果find_filesystem返回的是file_system_type的指针，则调用方会拿到一个权限比较大的地址，即可以直接操作file_system_type结构。而源代码返回的是file_system_type指针的地址，也就是file_system_type的一个成员的地址，适合做链表扩展，访问file_system_type结构就有点麻烦。这样的写法看起来，有那么一点代码隐藏的味道。

不知道看法对否？

[小魔菇]

指针的指针 这样就可以修改文件链表中的项

[jianmin09]

指向指针的指针，便于链表操作；第二条有待考证。

[jianmin09]

指向指针的指针，便于链表操作；第二条有待考证。