Linux Kernal VFS-System Call：Read

2021SC@SDUSC

Read is a system call in vfs layer, which means the function directly related to users' process and can be called by those programs.As we see in the very beginning, vfs is a layer provided by kernal to minimize the difficulty for users to operate files in different file systems not only settled in disks but also other virtural files of different devices, hardware.

Before we analyse function read, we might go back the the past few blogs which discussed about open function, since if you want to read data in the file, you gonna open it at first.So what does this open function achieved, and what does it provided to users?

The very important and only thing that open does is to find a file's necessary structs which is the actual key for kernal to read or write bits.Firstly find the target's dentry through algorithm called Path Walking, in function openat, and through the dentry find the inode connected to the target.An fd will be newed and put in the fd list of the file, also a new struct will be build in the open file list.In the end, the newly built fd is connected to the dentry and inode of the file, so the outer side of ther kernal, which is fd for users to use, and inner side of the kernal which is inodes and dentry for the kernal to use is finally connected, and user doesn't need to care about those inner things to access the file with system calls like read and write and so on.

The answer is quite obvious for the moment, since read is a system call for processes, fd will be used to find the inode, through which the kernal does as user's command.

The api is sys_read, and is located in fs/read_write.c.How does system call READ leads to sys_read is another question about system call, so we might talk about it if we have any spare time in the end.

 

SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
{
	return ksys_read(fd, buf, count);
}

Well, ksys_read is the name in latest versions, but it is similar to sys_read.

ssize_t ksys_read(unsigned int fd, char __user *buf, size_t count)
{
	struct fd f = fdget_pos(fd);
	ssize_t ret = -EBADF;

	if (f.file) {
		loff_t pos, *ppos = file_ppos(f.file);
		if (ppos) {
			pos = *ppos;
			ppos = &pos;
		}
		ret = vfs_read(f.file, buf, count, ppos);
		if (ret >= 0 && ppos)
			f.file->f_pos = pos;
		fdput_pos(f);
	}
	return ret;
}

As a parameter, fd is used to find inode and other data of the file.fdget_pos and fdput_pos is operations about locks, and file_ppos gets the position for reading the file.

In elder versions like 4.17, the part of the code is like this:

     if (f.file) {

                loff_t pos = file_pos_read(f.file);

                ret = vfs_read(f.file, buf, count, &pos);

                if (ret >= 0)

                        file_pos_write(f.file, pos);

                fdput_pos(f);

        }

We can see that in elder version, there are two functions for saving position in fd, file_pos_read() and file_pos_write.However, in the version we're now analysing, the functions are removed, instead position is temporarily taken out in pos and ppos(used to change the value of pos after the method is done), and when vfs_read is finished, pos will immidiatly saved back to fd.The later version is definately better than the old one, because the work is done all together.

As we can see, the most important part of the function is in vfs_read which is a very complicate function with so many methods and defines within it.We will use the rest of the blogs to fully conquer the part, if possible ,goes to system call write.