Updating makefs(8) with updates from NetBSD

[Ed Maste]

Hi all,
While looking quickly through makefs upstream for fixing a PR...

This comment prompted a brief discussion off the mailing list, but I
feel I should bring it back here as I've heard from a few others with
an interest in updating makefs.

Makefs originated in NetBSD, but we haven't treated it as contrib code
- the initial import was done directly in usr.sbin/makefs in r186335.
Since that time we've had a comprehensive sync w/ NetBSD (r214921), a
sync of cd9660 support only (r224762), and a number of individual
fixes either taken from NetBSD or committed to FreeBSD first and
submitted to NetBSD. We also have changes that I don't believe made it
to NetBSD.

I'd like to see another makefs sync with NetBSD, specifically to pick
up support for FAT filesystems -- -t msdos.

Since a few of us have been looking at makefs updates and/or bug fixes
I'd like to figure out what the best path forward is, so that we don't
duplicate or waste effort. It seems the options are:

(a) update makefs in usr.sbin/makefs directly, either by iterating on
NetBSD changes and importing one by one, in small groups, or as one
massive update

(b) bring the latest NetBSD makefs into contrib, retrofit mergeinfo as
best we can, and replay all of our local changes, submitting to NetBSD
as we go

(c) push all of our changes and in-progress bug/coverity fixes to
NetBSD, then replace makefs with NetBSD's, and import the dependencies
from NetBSD

Option (b) or (c) seem to be cleaner and is probably less work overall
-- there are more than 100 commits in NetBSD after our last sync. It
has the downside of limiting work that can be done by multiple people
concurrently though, and includes file system support that's not of
interest to us (e.g. v7fs).

Note that NetBSD's makefs is set up to build on many different host
operating systems already (FreeBSD, Linux, OS X etc.) because they
build it as part of their build.sh build environment. This relies on
the NetBSD versions of various headers (e.g. ffs*.h) and other tools
(e.g. newfs_msdos). I don't think we want to pull in another copy of
those headers and tools for the sake of makefs though and prefer (b)
to (c).

Although I suspect it's more work overall I think we're most likely to
make progress with option (a), merging over individual changes or
groups of changes. I'd like to know what those who've worked on makefs
updates in the past and others with an interest in makefs prefer to do
here.

[John-Mark Gurney]

Post by Ed Maste
Option (b) or (c) seem to be cleaner and is probably less work overall
-- there are more than 100 commits in NetBSD after our last sync. It
has the downside of limiting work that can be done by multiple people
concurrently though, and includes file system support that's not of
interest to us (e.g. v7fs).

If we changed to linker sets instead of a hard coded table in makefs.c,
then we just don't compile in the v7fs files, and no other changes are
needed...

I'd be willing to make the changes to support linker sets for this..

This would also allow dynamic loading of fs modules w/o much trouble
through LD_PRELOAD iirc...