UNIX Filesystems: Evolution, Design, and Implementation

Pathname Resolution

System calls often specify a pathname that must be resolved to an inode before the system call can continue. For example, in response to:

fd = open(“/etc/passwd”, O_RDONLY);

the kernel must ensure that /etc is a directory and that passwd is a file within the /etc directory.

Where to start the search depends on whether the pathname specified is absolute or relative. If it is an absolute pathname, the search starts from rootdir, a pointer to the root inode in the root filesystem that is initialized during kernel bootstrap. If the pathname is relative, the search starts from u_cdir, the inode of the current working directory. Thus, one can see that changing a directory involves resolving a pathname to a base directory component and then setting u_cdir to reference the inode for that directory.

The routine that performs pathname resolution is called namei(). It uses fields in the user area as do many other kernel functions. Much of the work of namei() involves parsing the pathname to be able to work on one component at a time. Consider, at a high level, the sequence of events that must take place to resolve /etc/passwd.

if (absolute pathname) {
        dip = rootdir
    } else {
        dip = u.u_cdir
    }
loop:
    name = next component
    scan dip for name / inode number
    iput(dip)
    dip = iget() to read in inode
    if last component {
        return dip
    } else {
        goto loop
    }

This is an oversimplification but it illustrates the steps that must be performed. The routines iget() and iput() are responsible ...