1 0 . 4
H O W I T R E A L LY W O R K S
165
The next two operations in this group of top-level vnode operations are
those that retrieve and set file system global information. The
rfsstat
func-
tion reads a file system info structure. This structure contains items such as
the name of the volume, the block size of the file system, the number of total
blocks, the number of free blocks, and so on. This information is used by
programs such as
df
or displayed by the
Get Info
menu item for a disk icon
on the desktop.
The function
wfsstat
allows programs to set information about the file
system. The only supported field that can be written is the name of the
volume. It would be very difficult to support changing the block size of a file
system, and no attempt is made.
The
rfsstat
and
wfsstat
routines are trivial to implement but are required
to provide global information about a file system to the rest of the system and
to allow editing of a volume name.
Vnode Support Operations
Beyond the mounting/unmounting file system issues, there are certain low-
level vnode-related operations that all file systems must implement. These
functions provide the most basic of services to the vnode layer, and all other
vnode operations depend on these routines to operate correctly. These opera-
tions are
op_walk
(*walk);
op_read_vnode
(*read_vnode);
op_write_vnode
(*write_vnode);
Most vnode operations, such as read or write, have a user-level function of
the same name or a very similar name. Such functions implement the func-
tionality that underlies the user-level call of the same name. The functions
walk
,
read vnode
, and
write vnode
are not like the other vnode operations.
They have no corresponding user-level call, and they are called with certain
restrictions.
The first routine,
walk()
, is the the crux of the entire vnode layer API. The
vnode layer uses the
walk()
function to parse through a file name as passed
in by a user. That is, the vnode layer "walks" through a file name, processing
each component of the path (separated by the "
/
" character) and asking the
file system for the vnid that corresponds to that component of the full path.
A short aside on path name parsing is in order. The choice of "
/
" as a
separator in path names is a given if you are used to traditional Unix path
names. It is unusual for people used to MS-DOS (which uses "
\
") or the
Macintosh (which uses "
:
" internally). The choice of "
/
" pleases us, but the
separator could certainly have been made configurable. We deemed that the
complexity that would have to be added to all APIs (both in the kernel and at
Practical File System Design:The Be File System
, Dominic Giampaolo
page 165