2406596e11
Instead of extending fsinfo_t it now holds a void * to file system specific data. This is then setup/cleaned up by the additional of 2 additional callbacks. Makes adding new filesystems simpler as almost no code has to be updated in the generic makefs code now.
129 lines
4.6 KiB
Plaintext
129 lines
4.6 KiB
Plaintext
$NetBSD: README,v 1.3 2004/12/20 20:51:42 jmc Exp $
|
|
|
|
makefs - build a file system image from a directory tree
|
|
|
|
NOTES:
|
|
|
|
* This tool uses modified local copies of source found in other
|
|
parts of the tree. This is intentional.
|
|
|
|
* makefs is a work in progress, and subject to change.
|
|
|
|
|
|
user overview:
|
|
--------------
|
|
|
|
makefs creates a file system image from a given directory tree.
|
|
the following file system types can be built:
|
|
ffs BSD fast file system
|
|
|
|
Support for the following file systems maybe be added in the future
|
|
ext2fs Linux EXT2 file system
|
|
fat MS-DOS `FAT' file system (FAT12, FAT16, FAT32)
|
|
cd9660 ISO 9660 file system
|
|
|
|
Various file system independent parameters and contraints can be
|
|
specified, such as:
|
|
- minimum file system size (in KB)
|
|
- maximum file system size (in KB)
|
|
- free inodes
|
|
- free blocks (in KB)
|
|
- mtree(8) specification file containing permissions and ownership
|
|
to use in image, overridding the settings in the directory tree
|
|
- file containing list of files to specifically exclude or include
|
|
- fnmatch(3) pattern of filenames to exclude or include
|
|
- endianness of target file system
|
|
|
|
File system specific parameters can be given as well, with a command
|
|
line option such as "-o fsspeccific-options,comma-separated".
|
|
For example, ffs would allow tuning of:
|
|
- block & fragment size
|
|
- cylinder groups
|
|
- number of blocks per inode
|
|
- minimum free space
|
|
|
|
Other file systems might have controls on how to "munge" file names to
|
|
fit within the constraints of the target file system.
|
|
|
|
Exit codes:
|
|
0 all ok
|
|
1 fatal error
|
|
2 some files couldn't be added during image creation
|
|
(bad perms, missing file, etc). image will continue
|
|
to be made
|
|
|
|
|
|
Implementation overview:
|
|
------------------------
|
|
|
|
The implementation must allow for easy addition of extra file systems
|
|
with minimal changes to the file system independent sections.
|
|
|
|
The main program will:
|
|
- parse the options, including calling fs-specific routines to
|
|
validate fs-specific options
|
|
- walk the tree, building up a data structure which represents
|
|
the tree to stuff into the image. The structure will
|
|
probably be a similar tree to what mtree(8) uses internally;
|
|
a linked list of entries per directory with a child pointer
|
|
to children of directories. ".." won't be stored in the list;
|
|
the fs-specific tree walker should add this if required by the fs.
|
|
this builder have the smarts to handle hard links correctly.
|
|
- (optionally) Change the permissions in the tree according to
|
|
the mtree(8) specfile
|
|
- Call an fs-specific routine to build the image based on the
|
|
data structures.
|
|
|
|
Each fs-specific module should have the following external interfaces:
|
|
|
|
prepare_options optional file system specific defaults that need to be
|
|
setup before parsing fs-specific options.
|
|
|
|
parse_options parse the string for fs-specific options, feeding
|
|
errors back to the user as appropriate
|
|
|
|
cleanup_options optional file system specific data that need to be
|
|
cleaned up when done with this filesystem.
|
|
|
|
make_fs take the data structures representing the
|
|
directory tree and fs parameters,
|
|
validate that the parameters are valid
|
|
(e.g, the requested image will be large enough),
|
|
create the image, and
|
|
populate the image
|
|
|
|
prepare_options and cleanup_options are optional and can be NULL.
|
|
|
|
NOTE: All file system specific options are referenced via the fs_specific
|
|
pointer from the fsinfo_t strucutre. It is up to the filesystem to allocate
|
|
and free any data needed for this via the prepare and cleanup callbacks.
|
|
|
|
Each fs-specific module will need to add it's routines to the dispatch array
|
|
in makefs.c and add prototypes for these to makefs.h
|
|
|
|
All other implementation details should not need to change any of the
|
|
generic code.
|
|
|
|
ffs implementation
|
|
------------------
|
|
|
|
In the ffs case, we can leverage off sbin/newfs/mkfs.c to actually build
|
|
the image. When building and populating the image, the implementation
|
|
can be greatly simplified if some assumptions are made:
|
|
- the total required size (in blocks and inodes) is determined
|
|
as part of the validation phase
|
|
- a "file" (including a directory) has a known size, so
|
|
support for growing a file is not necessary
|
|
|
|
Two underlying primitives are provided:
|
|
make_inode create an inode, returning the inode number
|
|
|
|
write_file write file (from memory if DIR, file descriptor
|
|
if FILE or SYMLINK), referencing given inode.
|
|
it is smart enough to know if a short symlink
|
|
can be stuffed into the inode, etc.
|
|
|
|
When creating a directory, the directory entries in the previously
|
|
built tree data structure is scanned and built in memory so it can
|
|
be written entirely as a single write_file() operation.
|