Chapter 10: Filesystems without Persistent Storage
❑ proc_dointvec_minmaxworks in the same way asproc_dointvec, but ensures that each number
is within a minimum and maximum value range specified bytable->extra1(minimum value)
andtable->extra2(maximum value). All values outside the range are ignored.
proc_doulongvec_minmaxserves the same purpose, but uses values with typeunsigned long
instead ofint.
❑ proc_dointvec_jiffiesreads an integer table. The values are converted to jiffies. A nearly
identical variant isproc_dointvec_ms, where the values are interpreted as milliseconds.
❑ proc_dostringtransfers strings between kernel and userspace and vice versa. Strings that are
longer than the internal buffer of an entry are automatically truncated. When data are copied
into userspace, acarriage return(\n) is appended automatically so that a line break is added after
information is output (e.g., usingcat).10.2 Simple Filesystems
Full-featured filesystems are hard to write and require a considerable amount of effort until they reach
a usable, efficient, and correct state. This is reasonable if the filesystem is really supposed to store data
on disk. However, filesystems — especially virtual ones — serve many purposes that differ from storing
proper files on a block device. Such filesystems still run in the kernel, and their code is thus subjected
to the rigorous quality requirements imposed by the kernel developers. However, various standard
methods makes this aspect of life much easier. A small filesystem library — libfs — contains nearly all
ingredients required to implement a filesystem. Developers only need to provide an interface to their
data, and they are done.Additionally, some more standard routines — in the form of theseq_filemechanism — are available to
handle sequential files with little effort. Finally, developers might want to just export a value or two into
userspace without messing with the existing filesystems like procfs. The kernel also provides a cure for
this need: The debugfs filesystem allows for implementing a bidirectional debugging interface with only
a few function calls.10.2.1 Sequential Files
Before discussing any filesystem library, we need to have a look at the sequential file interface. Files in
small filesystems will usually be read sequentially from start to end from userland, and their contents are
created by iterating over several items. These could,for instance, be array elements. The kernel traverses
the the whole array from start to end and creates a textual representation for each element. Put into kernel
nomenclature, one could also call this making synthetic files from sequences of records.The routines infs/seq_file.callow implementing such files with minimal effort. Despite their
name, seeking is possible for sequential files, but the implementation is not very efficient. Sequential
access — where one item is read after another — is clearly the preferred mode of access; simplicity in
one aspect often comes with a price in other regards.The kprobe mechanism contains an interface to the aforementioned debug filesystem. A sequential file
presents all registered probes to userland. I consider the implementation to illustrate the idea of sequen-
tial files.