[ This is a general reply to several messages.  I'd really like to see
  this take off and make a much cleaner system...
  Is Richard Wackerbarth out there anywhere?  He had expressed some
  interest in working in this area, too.

  The writing after a '*****' down below is a pointer for more work
  for someone other than me...  ;-)
]

[ From Stan: ]
> Well, this morning I sifted through the sources more carefully, and got
> the booter to build under MPW, just for grins.  As you might imagine, MPW C
> found many sins that Think C overlooks!

I can imagine.  The booter is a set of hacks on top of an original hack ;-)
Really...  :-(

Ideally, all three current applications should be rolled into one
consistent application (ideally, along with some fsck functionality,
I think--this would allow basic manipulation of the file system on
a machine that can't get as far as actually booting).  Unfortunately,
I'd also like to see the booter as small as possible (so it can fit on a
bootable floppy or minimal HFS filesystem and won't take any time to
load).  This could possibly be accomplished through some on-demand
segment loading feature, I think, but I haven't played around with
the MacOS that much.

The only reason I'd kind-of like to see disk partitioning is that the
A/UX disk partitioner is the only one that hasn't fubar'd a disk of mine
in some fashion at some time and can read all of the partition data from
any partitioning software's attempts to write it.  Way to go, Apple!

> Here's a proposal for a new Mac-side source organization that puts all
> the various source bits for both programs into a single folder:

The one addition I'd make is to put the ufs and gzip libraries each
into it's own subdirectory and make the same set of projects/Makefiles
(THINK, MPW, Unix) for them.  Granted, they will be relatively static,
but I'd like to have all the source out there (not to mention that the
gzip license requires it ;-).

> (Cygnus hasn't advertised this,
> but I actually have all of GCC/GAS/LD/BINUTILS/GDB building and running
> under MPW, using sources that currently being distributed by the FSF!)

Cool beans!  So does that tool chain build mac apps?  Could we strangle
it into a system to build these applications?  We've thought about using
something like MacMiNT for a development env. for these tools, but we
never got off the ground in using them.  Does Cygnus plan to sell or
release these anytime?

> I would suggest not attempting to use Think's or MPW's console packages,
> instead just using the booter's Output.c code for output and making a
> dialog to handle the collection of input for the minishell (could even
> have a menu of minishell commands, but perhaps not too important).

Sounds good to me.  It's much more general that way.

> None of this really affects the actual workings of installing and booting,
> but I'd like to think about some way to know whether things haven't been
> broken accidentally.  Has anybody thought about using some sort of
> emulation/simulation so that a real machine's filesystem isn't trashed?

I have not.  That's a great idea as long as the emulation/simulation is
valid ;-)  I used a scratch partition when working on it--to check the
validity, I booted and ran fsck on it after mucking about.

> Uh, I don't understand the advantage of this change... for speed perhaps?

Brad mentioned a few.  Largely it's to avoid having to have more than
libsa's understanding of the ufs ported to MacOS.  The minimal ufs code
that's in the installer can read the root directory and a file from it.

> :-)  I was thinking more at the level of throwing away dead and/or obsolete
> code.  I was just showing jtc the two-argument calls to free() that are in
> the ufs code that the installer uses now, it was both entertaining and
> horrifying...

The installer is a good example of code that one doesn't want to give
away because it will be clear to knowledgable observers that it's a
really big hack.  I am honestly surprised that it works and it still
gives me the willies.  That code is basically the 0.9 ufs with the
buffer caching ripped out and some hacks to get it to run.

  [ on booting BSD with a mechanism to install from within a running
    (single-user) kernel. ]
> Hmmmm.  It seems more fragile, although when I think through various

It is, and it doesn't allow the utilities to be used on unsupported
systems, but it's little different from how the i386 and others work
now, except they're booting off a floppy.

I honestly have little opinion on which way we go.  If I had to choose
between the two right now, I'd probably opt for the robust mac-side
program because it does allow leverage of the MacOS interface for
installing (for the Mac-weenies ;-) and does not require potentially
hairy mucking about in the kernel.

[ From Jeff: ]
> I have a suggestion that some of you may (or may not ) want to hear.  A
> friend of mine has a FreeBSD system and the installation procedure for
> their latest release is *way* cool.

I'd like to take a look at that, too, because we might be able to use
some of their ideas and process with either direction we take.  They
are apparently doing some things right over in the FreeBSD camp as they
seem to have a steadily growing following and I've seen a lot of praise
of their new install process (and Jordan seems proud of it ;-).

> Basically, they install only the minimal set of binaries needed to perform
> networking including a kernel built with all options (slip, ppp, ethernet,
> or nfs, etc.). From there, you boot the system and an run an install script
> which configures the networking options (i.e., slip, ethernet, ppp, etc)

We could conceivably do something similar right now.  I think that with
the devices built and the base package installed, you can boot and setup
SL/IP or PPP.  If the ethernet driver works well enough, you might be
able to use that to ftp, too.  I didn't want to document that part,
though!  If we take the mac-side approach, you should have access to
AppleTalk, MacPPP, MacSLIP, MacTCP, etc...

> But of course, things like adb-lockup and instabilities in
> the networking code could potentially screw things up.

Hopefully we'll get beyond that fairly soon...  :-(

> Now, I've only looked at the FreeBSD install scripts briefly, and do not
> have the time to work on it for MacBSD (or even type this message, for that
> matter), so I thought why not let you guys know about it.

Thanks for the pointer...

*****

What I'd like to see happen:
	I would like to see others contribute _some_ input on the
advantages of one approach over the other (mac-side install/mkfs/boot
vs. mac-side boot and special kernel facilities for BSD native install).
I would also like to see someone take the ball for coordinating
development along whatever path they deem most worthy.  This person
should draw up a plan and assign volunteers to tasks (documentation,
coding a library, coding an application, whatever).  I would like to
have some input in which direction is taken and the implementation
thereof (if you want kernel changes, you'll go through me, anyway ;-).

So, any suggestions, comments, criticisms, or volunteers?

Cheers,
-allen

-- 
Allen Briggs - end killing - allen.briggs@vt.edu ** MacBSD == NetBSD/mac68k **