Chapter
1
Introduction
Files and directories are common abstractions, which we encounter daily when sending an
e-mail attachment, downloading a new application or archiving old information. Those
same abstractions may be leveraged in an embedded system for similar tasks or for unique
ones. A device may serve web pages, play or record media (images, video or music) or log
data. The file system software which performs such actions must meet the general
expectations of an embedded environment—a limited code footprint, for instance—which
still delivering good performance.
1-1 WHAT IS A FILE SYSTEM?
A file system is a collection of files and directories; since directories are containers of files, a
hierarchical organization results. A PC operating system such as Windows or Linux presents
its file systems through a visual interface (e.g, “Windows Explorer”), with a tree-like
structure of entries that can be moved, renamed or deleted with menus or actions like
“dragging and dropping”. Alternatively, a headless system like DOS (or any other command
line) integrates utilities to accomplish the same operations.
Above, we stated that a system “presents its file systems”—file systems plural—because
each drive is a separate file system, a separate collection of files. Each of these is anchored
by some unique drive letter (Windows) or mount point (Linux) within the larger context of
a “virtual” file system wherein every entry has a unique identifier. (Within the “everything is
a file” mentality of Linux, this is taken further, but that is beyond this discussion.) Being
separate, each file system may have a different format—one may be FAT, the next NTFS—
and will be located on different physical devices or on separate partitions of the same
device.
If files are to be read from a volume, file system software is required, with three basic
elements. First, a device driver must be able to read and write to the device. Next, a file
system driver must be able to parse the device’s on-disk structures to read the names,
15