A . 4
T H E A P I
The next most important data structure is the
. A file system
can define a
any way it needs to since it is primarily an internal
data structure not seen by the higher levels of the kit. A
may be as
simple as an unsigned integer, or it may be a full data structure with several
must be able to address any position on the disk.
Related to the
. If a file system uses disk ad-
dresses to locate i-nodes (as is done in BFS), then the
data type is
likely to be the same as a
. If an
is an index to an i-node
table, then it may just be defined as an integer.
Building on these two basic data types, the
data structure stores
all the information needed by an i-node while it is in use in memory. Using
structure, the file system must be able to access all of a file's data
and all the information about the file. Without the
is little that a file system can do. The file system kit makes no distinction
structures that refer to files or directories. The file system
must manage the differences between files and directories itself.
The API for each of the components of the kit follows several conventions.
Each component has some number of the following routines:
--The create routine should create the on-disk data structure needed
by a component. Some components, such as files and directories, can be
created at any time. Other components, such as the block map, can only
be created when creating a file system for the first time.
--The init routine should initialize access to the data structure on a
previously created file system. After the init routine for a component, the
file system should be ready to access the data structure and anything it
contains or refers to.
--The shutdown routine should finish access to the data struc-
ture. After the shutdown routine runs, no more access will be made to the
/free--These routines should allocate a particular instance of a
data structure and free it. For example, the i-node management code has
routines to allocate and free individual i-nodes.
In addition to this basic style of API, each component implements addi-
tional functions necessary for that component. Overall the API bears a close
resemblance to the BeOS vnode layer API (as described in Chapter 10).
The following subsections include rough prototypes of the API. Again, this
is not meant as an implementation guide but only as a coarse overview of
what the API contains. The documentation included with the file system kit
archive contains more specific details.
Practical File System Design:The Be File System
, Dominic Giampaolo