Linux Kernel Architecture

Chapter 8: The Virtual Filesystem

File access and ownership rights are held ini_mode(file type and access permissions) and ini_uidand

i_gid(the UID and GID associated with the file).

i_rdevis needed when the inode represents a device file. It indicates the device with which communica-

tion is to take place. Note thati_rdevis only a number, not a data structure! The information contained

in this number is, however, sufficient to find everything interesting about the device. For block devices,

this would be an instance ofstruct block_device, as is discussed in Chapter 6.^6

If the inode represents a device special file, then the elements contained in the anonymous union that

followsi_rdevcontain pointers to specialized data structures about the devices.

i_bdevis used for block devices,i_pipecontains relevant informationfor inodes used to implement

pipes, andi_cdevis utilized for character devices. Since an inode cannot represent more than one type of

device at a time, it is safe to keepi_pipe,i_bdev,andi_cdevin a union.i_devicesis also connected to

device file handling: It allows a block or character device to keep a list of inodes that represent a device

file over which it can be accessed. While in many cases a single device file per device will suffice, there are

also numerous possibilities — chroot’ed environments, for instance — where a given block or character

device will be accessible via more than one device file and thus more than one inode.

Most of the remaining elements point to compound data types whose meanings are discussed below in

this chapter.

InodeOperations

The kernel provides a large number of functions for performing operations on inodes. A set of function

pointers is defined to abstract the operations because data are manipulated by the specific filesystem

implementation. The call interface always remains the same, although the actual work is carried out by

implementation-specific functions.

The inode structure has two pointers (i_opandi_fop) to arrays that implement the above abstraction.

One relates to the inode-specific operations, and the other provides file operations. A reference to the

file operations structure is included not only in the inode structure but also in the file structure. We take

a closer look at this after we have examined how files are represented in the kernel. Here, suffice it to

say that file operations deal with manipulating the data contained in a file, while inode operations are

responsible for managing the structural operations (e.g., deleting a file) and metadata associated with

files (e.g., attributes).

All inode operations are grouped together in the following structure: