The VFS Layer

The VFS layer is a software layer between the system call and the actual file system. The VFS layer provide a common interface for any given file system. This makes it possible to relative easy to intergrades a new file system in the Linux kernel, as all which have to be done is implement the calls from the VFS. From the user space point of view the programmer can disregard from which file system is used, as it is taken care of. Beside from providing a common interface to the user space programmer, and another common interface fore the different file systems, it can also do some optimization in terms of caching and skipping operations as closing a file which have not been written to.

The functions provided on the system call side is not equal in terms of name, parameters, amount or executions time to the functions on the file system side, and can not be mapped one to one.

On the system call side those are some of the functions provided: (the following is just a few of the more well known, and are copied from syscalls.h. In user space they are named without the _sys)

asmlinkage long sys_mount(char __user *dev_name, 
                          char __user *dir_name, 
                          char __user *type, 
                          unsigned long flags, 
                          void __user *data);

asmlinkage long sys_mkdir(const char __user *pathname, 
                          int mode);

asmlinkage long sys_chdir(const char __user *filename);

asmlinkage long sys_chmod(const char __user *filename, 
                          mode_t mode);

asmlinkage long sys_stat(char __user *filename,
             struct __old_kernel_stat __user *statbuf);

asmlinkage long sys_open(const char __user *filename,
                         int flags, 
                         int mode);

asmlinkage long sys_close(unsigned int fd);

On the VFS side the functions provided is divided into the following four categories:

• super_operations
• inode_ operations
• file_ operations
• dentry_operations

I will not dick into which functions are to be found but only mention a few functions:

create(dir, dentry, mode, nameidata)

lookup(dir, dentry, nameidata)

unlink(dir, dentry)

mknod(dir, dentry, mode, rdev)

read(file, buf, count, offset)

aio_read(req, buf, len, pos)

write(file, buf, count, offset)

An example on that functions can not be mapped one to one between the system call interface, could be the system call open. The system call open is handled by the function sys_open¹¹ and is among other functions in the VFS API calling lookup. To give tiny insight in what happens in the VFS part of the kernel when the open system call is issued, I have described the most important steps which are preformed (the source for the following list is [4] and the Linux kernel version 2.6.20-gentoo-r8 examined by cscope):

1. Calls getname( ) to read the file pathname from user space.
2. Calls get_unused_fd( ) to get a new file descriptor in the process address space
3. Calls filp_open( ) function (and passing thru arguments such as pathname). This function is executing the following steps:
   1. Call open_namei( ) which invokes the lookup function which are to be fund in the given file system implementasion.
   2. Call dentry_open( ) chich allocate a file object in the kernel, and fill in the properties.
   3. Return the address of the file object.
4. Writes the address returned by dentry_open( ) to the following feild in the process data structor current->files->fd[fd]
5. Returns the file descriptor.