> 
> On Wed, 5 Feb 1997, Bill Studenmund wrote:
> 
> I believe the possibility was raised, at one time, of using a mini-root
> and doing an install from within NetBSD.  I've been pondering this
> recently....  Here's my two cents or so.  Basically the idea is to create
> an 'installer' which is nothing more than a user interface wrapper around
> a whole bunch of utilities that already exist.  Let me know what y'all
> think.

I like the idea, but I think we have more flexability in some places. The
i386 port uses a shell script, and two 1.4 MB floppies for all the meat.
We should be able to do something comparable.

> 12 Step Installer Program
> 
> 1.	MacOS side installer grabs configuration information, such as
> 	getting the IP number and config information from
> 	MacTCP/OpenTransport if that's possible....
> 2.	MacOS side installer decompresses and builds microroot.
> 3.	MacOS side loads microkernel and microroot.

shrunk kernel? We don't have a microkernel. :-) 

> 4.	Switch to NetBSD
> 5.	NetBSD installer gets config information w/ disklabel, stores in
> 	table.
> 6.	Installer menu provides ability to create partitions using pdisk
> 	from mklinux (with modifications, no doubt, but I suspect a large
> 	part of the code would work).  Then, use mkfs/newfs to create the
> 	NetBSD fs.
> 7.	Installer menu allows you to extract tarballs, ungzipping then if
> 	necessary.
> 8.	Installer menu allows you to install the kernel of your choice,
> 	directly from the MacOS disk (hcopy or whatever).
> 9.	Installer menu allows you to spawn a mini-shell, allowing _basic_ 
> 	manipulation of the filesystem (rm, rmdir, cp, mv, etc.).
> 10.	Installer menu allows you to set up networking.  Two choices:
> 	A.	LAN Setup (prompts for confirmation before using MacOS
> 		settings)
> 	B.	PPP setup (prompts for send-expect pairs, like linux
> 		setnet)

All of NetBSD could use this feature!

> 12.	When the user quits, the system reboots into MacOS, and the old
> 	installer automagically executes (then removes the alias to itself
> 	from startup items folder) and allows the user to perform
> 	additional file transfers, etc.
> 
> Constraints:
> 
> 1.	The microkernel and microroot, complete with a little operating
> memory, must fit in a 5 Meg system without swapping, or must make
> provisions for swapping to a MacOS file (VM Storage, anyone?)
> 2.	The following programs would be required in the microroot:
> 	A.	mkfs/newfs
> 	B.	gunzip
> 	C.	tar
> 	D.	NetBSD-side installer
> 	E.	setnet-like program (shells are too big, sorry)
> 	F.	a drastically reduced kernel.

I'd disagree w/ E. sh is only 260k, staticly linked. We DON'T have
to staticly link, so it'll be smaller. I think we'd win on
maintainability and readability if we stick w/ shell scripts.
i386 uses them. :-)

> 3.	The following files would need to be included:
> 	A.	/dev/sdxx
> 
> The big kicker is number 2 at the top.  The idea is, if programs like rm,
> etc. won't fit, a pared down version is made available w/o the mini-shell. 
> If you only have three drives, there's no reason to include sd3x+, etc. 
> If memory were really tight, a stripped down microkernel might be used.... 
> One without networking, without such things as ncrscsi96 (this assumes
> that no quadra would be strapped for memory, which may or may not be an
> accurate assumption, UYOJ....), and the support for a bunch of the
> graphics stuff could be eliminated.  All you'd need is the basic console
> code.  No need for the audio beep support, that can be cut....  No need
> for floating point coprocessor support, since the installer really should
> use statically linked binaries with the better routines.  You _would_ need
> fpe, though.  :-)  Also, the big question would be whether the shared
> library support would take more or less space than the statically linked
> binaries (rm, cp, mkdir, rmdir, gunzip, tar, mkfs/newfs, installer, setnet
> program, that's about it).  I tend to think that in a 'microroot'
> situation (extreme of a miniroot), shared libs would be too bulky, but I'm
> not certain of that.  Again, UYOBJ.  :)

I think we need to look at how other ports take care of things. A lot of
these issues (fitting it all into a small space) have been delt with.
It is common for install kernels to be stripped down, but some stripping
might be not worht the hassle. I think shared libraries will be a GOOD
win, as they are shared on disk and in memory. We might just, though,
use different libraries than in the standard distribution. Also, there might
be a really-stripped version, and a not-so-stripped version.

One piece which will help with this is macfs. I got into it explicitly for
this use. We can keep the .tgz files on a MacOS partition, and untar them
directly. I did exactly this when I was installing 1.2, so I know it
works. The one problem w/ macfs right now is that it will randomly crash hard
(address error) in multi-user. I think we might have stack-overwrite
problems like what was mentioned on current-users recently.

Let's hash this out some more. I think we can get something in place for
1.3. Also, if we keep things as similar to other ports, we can leverage off
each other.

Take care,

Bill