For any particular partition, it is presumed that only one of the
normal filesystems such as FAT, FFS, or ext2fs can be used, so
there is a switch table managed by the functions in
disk_io.c. The notation is that you can only mount one at a
The block list filesystem has a special place in the system. In addition
to the normal filesystem (or even without one mounted), you can
access disk blocks directly (in the indicated partition) via the block
list notation. Using the block list filesystem doesn't effect any other
The variables which can be read by the filesystem backend are:
The current BIOS drive number (numbered from 0, if a floppy, and
numbered from 0x80, if a hard disk).
The current partition number.
The current partition type.
The drive part of the root device.
The partition part of the root device.
The current partition starting address, in sectors.
The current partition length, in sectors.
True when the dir function should print the possible completions
of a file, and false when it should try to actually open a file of that
Filesystem buffer which is 32K in size, to use in any way which the
filesystem backend desires.
The variables which need to be written by a filesystem backend are:
The current position in the file, in sectors.
Caution: the value of filepos can be changed out from
under the filesystem code in the current implementation. Don't depend on
it being the same for later calls into the backend code!
The length of the file.
The value of disk_read_hookonly during reading of data
for the file, not any other fs data, inodes, FAT tables, whatever, then
set to NULL at all other times (it will be NULL by
default). If this isn't done correctly, then the testload and
install commands won't work correctly.
The functions expected to be used by the filesystem backend are:
Only read sectors from within a partition. Sector 0 is the first sector
in the partition.
If the backend uses the block list code, then grub_read can be
used, after setting block_file to 1.
If print_possibilities is true, call print_a_completion for
each possible file name. Otherwise, the file name completion won't work.
The functions expected to be defined by the filesystem backend are
described at least moderately in the file filesys.h. Their usage
is fairly evident from their use in the functions in disk_io.c,
look for the use of the fsys_table array.
Caution: The semantics are such that then `mount'ing the
filesystem, presume the filesystem buffer FSYS_BUF is corrupted,
and (re-)load all important contents. When opening and reading a file,
presume that the data from the `mount' is available, and doesn't
get corrupted by the open/read (i.e. multiple opens and/or reads will be
done with only one mount if in the same filesystem).
Published under the terms of the GNU General Public License