On Sun, 4 Jul 2004, Quark IT - Hilton Travis wrote:
> > From: Peter Curran [mailto:peter at closeconsultants dot com] 
> > Sent: Saturday, 3 July 2004 20:19

> > The tarball includes everything you need to modify a standard 
> > 1.1 m0n0 image to include the module, this could be done on a 
> > none-freebsd machine if needed. 

Though not all non-FreeBSD machines.  Even OS X, with all its FreeBSDisms,
can't manipulate m0n0wall images, which I suspect is due to its not
supporting the BSD partitioning format (since it *does* support UFS).

> Shouldn't a module just be able to be uploaded to a running m0n0wall
> system in a similar way to a new firmware?  Making a module that needs
> to have the original image edited and the "module" code included is more
> like hacking the base than adding a module to me.

Well, "similar to a new firmware" wouldn't work, because that overwrites
the entire "disk" with the already-prepared image.  The only reason the
config file survives is by copying it to RAM and back again, and *that* is
only possible because it lives outside the mfsroot filesystem.

One possible, albeit inefficient, approach would be to have a place where
it looks for tarballs at boot time and unpacks them to the mfsroot.  If
this place were /conf, they'd automatically survive firmware upgrades, but
if they grew too large they could run into space limitations in the
temporary RAM disk or even the boot "disk" itself.

Putting add-ons in a separate partition would avoid these problems, but
then either the size of the extra partition would need to be fixed, or the
normal firmware upgrade procedure would need to avoid overwriting the
disklabel (making the initial install different from an upgrade).

					Fred Wright