> My questions to the studio audiance:
> 
> 1) How long, in seconds, should the total time be that you are given
>    to type something to the boot prompt before it goes its merry way?

It should be configurable.


> 2) There is no single #include file with parameters like this included
>    in all the boot code files. Should there be? It would probably be
>    better if there was such a thing.

probably not.  it should be "run-time" configurable.  8-)

another question to ask is:
	"where should console output go"?

and my answer to that is "it should be configurable, too."


> 3) The boot software has a number of cosmetic uglynesses.
> 
>    a) The boot software is very confusingly named. There is all sorts
>       of obsolete stuff created. Why do we still have fdboot, sdboot
>       and wdboot when they are all the same? Can anyone think of a
>       better name for the two parts than *boot and boot*
>       (i.e. bootbios and biosboot), which is damn confusing to any
>       sane person? Should these just be named boot1 and boot2 to
>       correspond with whats listed in README.386BSD

xxboot and bootxx work for me...  (they're what i was using on the
alpha until i changed the way my boot code worked...

"why is there still an i386/stand, and why is i386/boot named that
(rather than i386/stand)?"


>    d) Why are changes to the boot blocks documented in version.c? Why
>       are the version numbers of the boot blocks manually updated in
>       that file?

because we wanted some way of tracking changes to the boot blocks...
(unless i'm mistaken, I implemented that...  was a long time ago,
though.)

if you don't put it there, where _do_ you put it?  You want it to be
sort -- a single overarching version number -- so you can't use the
version numbers from any of the individual source files.  You want it
to be updated when there are significant changes (feature additions,
bug fixes) to the boot blocks, so using the version from a single file
won't do, either...


>    e) what the heck is the arch/i386/stand directory for any more,
>       anyway? Is it just obsolete and confusing? Should it go the way
>       of The Dodo since it is no longer of any real use at all?

well, really, boot programs belong in ..../stand, not ..../boot.
(the only programs that use ..../boot are vax and i386).

also, it would be Nice if there were more "standalone" utilities.
e.g. a standalone ls, etc., would be nice.  (AND NO, THEY SHOULD NOT
BE BUILT INTO THE BOOT BLOCKS...)


>    g) Speaking of obsolete, how about arch/i386/Makefile...

in general (and it's very unfortunate), kernel tags just Don't Work in
NetBSD.  it's very annoying sometimes (until you learn where
everything you ever use is, by heart...  8-).


above, i alluded to the fact that there are things that should be
run-time configurable.  BSDI does something like this.

As i recall, their boot block just loads /boot (or something like
that), which then:
	(1) reads a config file from the file system to determine
	    what to do, then
	(2) acts on the contents of the config file.


I'm pretty sure that they allow you to specify:	
	(1) where input/output comes from and goes to
		(i.e. serial port, etc.)
	(2) whether or not to prompt for alternate kernels.

they may also allow you to specify:
	(3) serial port settings, for serial console, and
	(4) time to delay, when prompting for alternate kernels.

There are many benefits to this scheme, and relatively few
disadvantages...


I've been moving in this directon on the alpha port.  luckily for me,
on the alpha most of information -- boot file name, console device,
etc., is provided by console software variables, so i don't have to
get it and use it myself...  since the console takes care of security
(allows a password protect to keep people from changing things and/or
specifying different boot file names, etc.)



chris