mfsBSD: Vendor import mfsBSD (mmatuska/mfsbsd@0da8061)

[soobinrho]

Summary

"mfsBSD is a toolset to create small-sized but full-featured mfsroot
based distributions of FreeBSD that store all files in memory (MFS)
[Memory File System] and load from hard drive, usb storage device or
optical media. It can be used for a variety of purposes, including
diskless systems, recovery partitions and remotely overwriting other
operating systems." (Martin Matuska)

This is the first out of three commits for integrating mfsBSD into
the main FreeBSD release tool set. This commit imports mfsBSD to the
/usr/src/contrib/mfsbsd location, and to streamline the future update
and maintenance process, I've introduced as little changes to the
upstream code as I possibly can. Just two modifications have been made:

1. Deleted mfsbsd/.cirrus.yml to prevent collision with

/usr/src/.cirrus.yml.

2. Increased mfsbsd/Makefile MFSROOT_MAXSIZE from 120m to 4700m

because otherwise makefs exits with the following error:

Creating and compressing mfsroot ... makefs: ...
size of 1237352448 is larger than the maxsize of 125829120.

Changelog: https://github.com/mmatuska/mfsbsd/commit/0da806178042b0d3cd20fb6b2e6e38a338a24b9c
Obtained from: https://github.com/mmatuska/mfsbsd
Sponsored by: Google, Inc. (GSoC 2023)
Signed-off-by: Soobin Rho <[e-mail]>

[jrm]

@soobinrho, this isn't something you have to worry about, but before this could be committed, it will require an actual vendor import and merge to contrib/. This is something one of us can deal with later.

[soobinrho]

In D41704#950458, @jrm wrote:

@soobinrho, this isn't something you have to worry about, but before this could be committed, it will require an actual vendor import and merge to contrib/. This is something one of us can deal with later.

Awesome. Thank you!

[soobinrho]

Updated mfsbsd/Makefile MFSROOT_MAXSIZE from 120m to 4700m.

[cperciva]

I don't like the idea of having "vendor" code as part of the FreeBSD release process. As far as I'm concerned, it's either part of FreeBSD or it isn't -- we can bring mfsBSD into FreeBSD if @mm wants but if we're going to do that it should be maintained in the FreeBSD tree.

[soobinrho]

In D41704#1068276, @cperciva wrote:

I don't like the idea of having "vendor" code as part of the FreeBSD release process. As far as I'm concerned, it's either part of FreeBSD or it isn't -- we can bring mfsBSD into FreeBSD if @mm wants but if we're going to do that it should be maintained in the FreeBSD tree.

Understood. @mm and @cperciva

[mm]

In D41704#1068276, @cperciva wrote:

I don't like the idea of having "vendor" code as part of the FreeBSD release process. As far as I'm concerned, it's either part of FreeBSD or it isn't -- we can bring mfsBSD into FreeBSD if @mm wants but if we're going to do that it should be maintained in the FreeBSD tree.

The question is base or ports.

The following points speak for base integration:

• private to FreeBSD
• improves user experience (rescue system, etc.)
• enriches the release process (new image possibilities etc.)
• helps developers (you can use mfsbsd for quick-and-dirty feature testing)

The following points speak against base:

• actually intended to be used together with packages, I have never done base-only releases so far

[bz]

In D41704#1124560, @mm wrote:

In D41704#1068276, @cperciva wrote:

I don't like the idea of having "vendor" code as part of the FreeBSD release process. As far as I'm concerned, it's either part of FreeBSD or it isn't -- we can bring mfsBSD into FreeBSD if @mm wants but if we're going to do that it should be maintained in the FreeBSD tree.

The question is base or ports.

The following points speak for base integration:

• private to FreeBSD
• improves user experience (rescue system, etc.)
• enriches the release process (new image possibilities etc.)
• helps developers (you can use mfsbsd for quick-and-dirty feature testing)

The following points speak against base:

• actually intended to be used together with packages, I have never done base-only releases so far

In ports:

• you can keep maintaining/developing it externally
• allows people to build on it more easily I think than within src
• you can integrate it so that you can have multiple "setups" to build for with the appropriate conf files, etc. for various images but only have one base port installation with "thin" child ports.
• use the options/menus there to deal with some variables to set
• can easily depend on other packages to automatically build or fetch
• can have patches per setup as well to be automatically applied ("for the quick and dirty testing for developers")
• ..

I think in short: there's plenty of these frameworks out there (I've seen others) that people tailored to their needs. And ports is good for the tailoring.

I love that this can generate output for multiple formats and is flexible as well but unless it gets a very tight integration into src|release I wouldn't know what to do with it in src[/contrib].
And maybe that's why it didn't move much here?
There's still tools/tools/nanobsd but ... and with pkg base coming it'll be a lot more interesting to have a tighter pkg integration than src I would envision?

Just my very personal 1/2ct.

[otis]

In D41704#1124560, @mm wrote:

In D41704#1068276, @cperciva wrote:

I don't like the idea of having "vendor" code as part of the FreeBSD release process. As far as I'm concerned, it's either part of FreeBSD or it isn't -- we can bring mfsBSD into FreeBSD if @mm wants but if we're going to do that it should be maintained in the FreeBSD tree.

The question is base or ports.

The following points speak for base integration:

• private to FreeBSD
• improves user experience (rescue system, etc.)
• enriches the release process (new image possibilities etc.)
• helps developers (you can use mfsbsd for quick-and-dirty feature testing)

The following points speak against base:

• actually intended to be used together with packages, I have never done base-only releases so far

My approach would be to integrate it into base (as that might allow to build mfsBSD images during release).
Regarding using packages, I don't see it as a showstopper, as packages are being used even now (they are being put into DVD images).