Linux Kernel Architecture

Chapter 8: The Virtual Filesystem

❑ Sockets for all network protocols

❑ Terminals for interactive input and output

Note that some of the objects are not necessarily linked with an entry in a filesystem. Pipes, for instance,

are generated by special system calls and then managed by the kernel in the data structures of the VFS

without having a ‘‘real‘‘ filesystem entry that can be accessed with typical commands such asrm,ls,and

so on.^3

Of particular interest (above all, in the context of Chapter 6) are device files to access block and charac-

ter devices. These are real files that typically reside in the/devdirectory. Their contents are generated

dynamically by the associated device driver when a read or write operation is performed.

8.3 Structure of the VFS

Now that we are familiar with the basic structure of the VFS and the interface to users, we turn our

attention to the implementation details. A large number of sometimes very lengthy data structures are

involved in the implementation of the VFS interface.It is therefore best to sketch out a rough overview

of the components and how they are interlinked.

8.3.1 Structural Overview

The VFS consists of two components — files and filesystems — that need to be managed and abstracted.

File Operations

As noted above, inodes are the means of choice for representing file contents and associated metadata. In

theory, only one (albeit very long) data structure with all the requisite data would be needed to imple-

ment this concept. In practice, the data load is spread over a series of smaller, clearly laid out structures

whose interplay is illustrated in Figure 8-3.

No fixed functions are used to abstract access to the underlying filesystems. Instead, function pointers

are required. These are held in two structures that group together related functions.

1. Inode Operations— Create links, rename files, generate new file entries in a directory, and
   delete files.


2. File Operations— Act on the data contents of a file. They include obvious operations such
   as read and write, but also operations such as setting file pointers and creating memory map-
   pings.

Other structures in addition to the ones above are needed to hold the information associated with an

inode. Of particular significance is the data field that is linked with each inode and stores either the

contents of the file or a table of directory entries. Each inode also includes a pointer to the superblock

object of the underlying filesystem used to perform operations such as the manipulation of the inodes

themselves (these operations are also implemented by arrays of function pointers, as we will see shortly).

Information on filesystem features and limits can also be provided.

(^3) Named pipes do have an entry in the filesystem so that they can be accessed.