准备：注：所有清单中代码均来自 linux2.6.11 内核原代码
读数据之前，必须先打开文件。处理 open 系统调用的内核函数为 sys_open 。
所以我们先来看一下该函数都作了哪些事。清单1显示了 sys_open 的代码（省略了部分内容，以后的程序清单同样方式处理）
清单1 sys_open 函数代码1
2
3
4
5
6
7
8
9
10
11
12
| asmlinkage long sys_open(const char __user * filename, int flags, int mode)
{
……
fd = get_unused_fd();
if (fd >= 0) {
struct file *f = filp_open(tmp, flags, mode);
fd_install(fd, f);
}
……
return fd;
……
}
|
代码解释：
- get_unuesed_fd() ：取回一个未被使用的文件描述符（每次都会选取最小的未被使用的文件描述符）。
- filp_open() ：调用 open_namei() 函数取出和该文件相关的 dentry 和 inode （因为前提指明了文件已经存在，所以 dentry 和 inode 能够查找到，不用创建），然后调用 dentry_open() 函数创建新的 file 对象，并用 dentry 和 inode 中的信息初始化 file 对象（文件当前的读写位置在 file 对象中保存）。注意到 dentry_open() 中有一条语句：
f->f_op = fops_get(inode->i_fop);
这个赋值语句把和具体文件系统相关的，操作文件的函数指针集合赋给了 file 对象的 f _op 变量（这个指针集合是保存在 inode 对象中的），在接下来的 sys_read 函数中将会调用 file->f_op 中的成员 read 。
- fd_install() ：以文件描述符为索引，关联当前进程描述符和上述的 file 对象，为之后的 read 和 write 等操作作准备。
- 函数最后返回该文件描述符。
图3显示了 sys_open 函数返回后， file 对象和当前进程描述符之间的关联关系，以及 file 对象中操作文件的函数指针集合的来源（inode 对象中的成员 i_fop）。
图3 file 对象和当前进程描述符之间的关系 到此为止，所有的准备工作已经全部结束了，下面开始介绍 read 系统调用在图1所示的各个层次中的处理过程。
虚拟文件系统层的处理：内核函数 sys_read() 是 read 系统调用在该层的入口点，清单2显示了该函数的代码。
清单2 sys_read 函数的代码1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| asmlinkage ssize_t sys_read(unsigned int fd, char __user * buf, size_t count)
{
struct file *file;
ssize_t ret = -EBADF;
int fput_needed;
file = fget_light(fd, &fput_needed);
if (file) {
loff_t pos = file_pos_read(file);
ret = vfs_read(file, buf, count, &pos);
file_pos_write(file, pos);
fput_light(file, fput_needed);
}
return ret;
}
|
代码解析：
- fget_light() ：根据 fd 指定的索引，从当前进程描述符中取出相应的 file 对象（见图3）。
- 如果没找到指定的 file 对象，则返回错误
- 如果找到了指定的 file 对象：
- 调用 file_pos_read() 函数取出此次读写文件的当前位置。
- 调用 vfs_read() 执行文件读取操作，而这个函数最终调用 file->f_op.read() 指向的函数，代码如下：
if (file->f_op->read)
ret = file->f_op->read(file, buf, count, pos);
- 调用 file_pos_write() 更新文件的当前读写位置。
- 调用 fput_light() 更新文件的引用计数。
- 最后返回读取数据的字节数。
到此，虚拟文件系统层所做的处理就完成了，控制权交给了 ext2 文件系统层。
在解析 ext2 文件系统层的操作之前，先让我们看一下 file 对象中 read 指针来源。
File 对象中 read 函数指针的来源：从前面对 sys_open 内核函数的分析来看， file->f_op 来自于 inode->i_fop 。那么 inode->i_fop 来自于哪里呢？在初始化 inode 对象时赋予的。见清单3。
清单3 ext2_read_inode() 函数部分代码1
2
3
4
5
6
7
8
9
10
11
12
13
| void ext2_read_inode (struct inode * inode)
{
……
if (S_ISREG(inode->i_mode)) {
inode->i_op = &ext2_file_inode_operations;
inode->i_fop = &ext2_file_operations;
if (test_opt(inode->i_sb, NOBH))
inode->i_mapping->a_ops = &ext2_nobh_aops;
else
inode->i_mapping->a_ops = &ext2_aops;
}
……
}
|
从代码中可以看出，如果该 inode 所关联的文件是普通文件，则将变量 ext2_file_operations 的地址赋予 inode 对象的 i_fop 成员。所以可以知道： inode->i_fop.read 函数指针所指向的函数为 ext2_file_operations 变量的成员 read 所指向的函数。下面来看一下 ext2_file_operations 变量的初始化过程，如清单4。
清单4 ext2_file_operations 的初始化1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| struct file_operations ext2_file_operations = {
.llseek = generic_file_llseek,
.read = generic_file_read,
.write = generic_file_write,
.aio_read = generic_file_aio_read,
.aio_write = generic_file_aio_write,
.ioctl = ext2_ioctl,
.mmap = generic_file_mmap,
.open = generic_file_open,
.release = ext2_release_file,
.fsync = ext2_sync_file,
.readv = generic_file_readv,
.writev = generic_file_writev,
.sendfile = generic_file_sendfile,
};
|
该成员 read 指向函数 generic_file_read 。所以， inode->i_fop.read 指向 generic_file_read 函数，进而 file->f_op.read 指向 generic_file_read 函数。最终得出结论： generic_file_read 函数才是 ext2 层的真实入口。 |
