NetBSD/usr.sbin/makefs
lukem 17d72c8a6b use NETBSDSRCDIR as appropriate 2002-09-18 03:54:26 +00:00
..
ffs Remove extraneous \n's in {err,warn}{,x} that used to be printfs. 2002-08-08 13:24:12 +00:00
Makefile use NETBSDSRCDIR as appropriate 2002-09-18 03:54:26 +00:00
README
TODO - clean up some debugging and verbose output 2002-02-06 02:17:14 +00:00
ffs.c d_namlen is a uint8_t, and thus will always be < MAXMANLEN + 1 (256), 2002-05-30 18:16:41 +00:00
makefs.8 If an entry is in the specfile but not in the underlying file system, and it's 2002-02-08 01:17:32 +00:00
makefs.c Roll in fixes to permit cross-compiling from non-NetBSD hosts. This 2002-01-31 22:43:33 +00:00
makefs.h remove (now) incorrect comment 2002-02-14 05:16:16 +00:00
walk.c If an entry is in the specfile but not in the underlying file system, and it's 2002-02-08 01:17:32 +00:00

README

$NetBSD: README,v 1.1.1.1 2001/10/26 06:50:48 lukem 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 & fragement 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:

    parse_options	parse the string for fs-specific options, feeding
			errors back to the user as appropriate

    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


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.