Re: libufs limitation trying to make newfs work on plain files

On Sun, Nov 30, 2008 at 05:31:10AM +0100, Luigi Rizzo wrote:
> 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.

Adding field to the structure is the most clean approach, but we do need
to make some supportive changes to keep our users happy, esp. when the
plan is to merge the change to the stable branch.

You proposal would introduce incompatibility in the ABI exposed by
one of the system library. The solution adopted by Linux and (recently)
by FreeBSD, is to use ELF symbol versioning. It seems that this case
can be handled by symver. As additional benefit, after your work
we would got one more symver-ed system library.