libufs limitation trying to make newfs work on plain files

libufs limitation trying to make newfs work on plain files

Hi,
I have been trying to modify newfs so that it could work on plain
files (the overall goal being to have more flexible tools to
manipulate filesystem images without the special privileges needed
by mdconfig).

Unfortunately, it seems that this cannot be done without modifying
the 'struct uufsd' in libufs.h so that it can deal with an offset in
the file (see below for a detailed description).

As far as I can tell libufs is only used by a small number of programs:
        /sbin/badsect:
        /sbin/dumpfs:
        /sbin/ffsinfo:
        /sbin/newfs:
        /sbin/tunefs:
        /usr/sbin/snapinfo:

so i don't think the change will create a major trouble in 
an upgrade. So, are there any objections if I work on such a
change planning to add it also in RELENG_7 once 7.1 is out ?

DETAILS
The problem i want to solve is make newfs able to create a partition
at an arbitrary offset in a file, so that we can create a disk image
without having to glue together the various filesystem and slice
in a second pass, and without requiring root privs to run mdconfig
or the like.

But right now newfs expects to open the actual partition (e.g.
/dev/da0s1f) and thus the partition data start at offset 0 within
the file descriptor. This assumption is in turn propagated down to 
libufs.

If you operate on a file representing the entire ufs slice, the
various partitions start at offsets !=0 (even worse, if the file
represent an entire disk image, the slice itself would be at a
non-zero offset). So you need to pass the offset to the start of  
the filesystem (in the general case an off_t) to the I/O routines
in libufs, and this information should be stored in the 'struct
uufsd'.

In principle one could use some tricks and describe the offset
with a few unused bits in the 'd_mine' field in struct uufsd:
 + 1 bit to signal that we are operating on a plain file so
   the filesystem does not start at offset 0;
 + 3 bits to indicate which partition we are using (a..h)
 + 1 bit to indicate that the slice is within a disk image
 + 2 bits to indicate which entry in the MBR describes the slice.

With this info the code could possibly locate the slice offset
within the image file, read the disklabel from there, then
add the offset of the partition within the slice, and without
needing to change the structure.

But clearly this is not as clean as adding an extra field to the
structure.

	cheers
	luigi