#define AUTHOR "thorpej@nas.nasa.gov (Jason Thorpe)"

/*
 * On Tue, 10 Oct 95 10:02:15 PDT 
 *  greywolf@defender.vas.viewlogic.com (Head Anarchy Conquest Knight Esquire of the Realm) wrote:
 * 
 *  > 	* Allow one to enter "-i path_to_init" to the bootloader and have it
 *  > 	  pass that to the kernel
 * 
 * That may not be practical on all ports.

Pardon my (probably complete) ignorance (and possibly incompetence :-),
but is there a space limit imposed by hardware as to what can be passed
in to the kernel by way of arguments, or what?

 * Maybe a better solution is a new 
 * flag for `boothowto', like RB_ASKINIT or something, which is set by the 
 * boot code by `-i' or something, and then the code in main() that starts 
 * init could prompt for a pathname if this flag is set...Of course, this 
 * would require that the backup init be on the root filesystem, and hence 
 * sort of defeats the purpose.

Well, yes, but I don't recall being able to do anything much different
than this in any case.

One ought to be able to have a backup init on the root filesystem unless
one has an extremely tight fit of the root filesystem into its partition,
and even then, init isn't *that* big (it's less than a meg, innit?).

A solution to this would be to install a meager /sbin in another
partition (along with boot blocks and maybe a kernel) such that one
would not have to boot from controller 0, target 0, unit 0, partition 0
in order to successfully come up single-user.  This, combined with the
-a flag (hopefully interpreted by /boot as well as /netbsd) would make
nearly anything possible.

Of course, this has a problem since init doesn't get called until after
the autoconfig, so init must live on the root filesystem.  *sigh*...

There must be a way to make things non-root-centric, though.  I mean, I
used to routinely get my bootblocks from one filesystem and my kernel from
another and my root filesystem from yet a third origin (due to things blowing
up and as an experiment):
/* the messages are probably not exact, but you get the idea */
b sd(0,0,6) -a
[loads bootblock(s) from sd0g]
Boot: sd(0,0,3)/vmunix -as	[ get kernel from sd0d]
Size: NNNNNNN+NNNNN+NNNNN bytes
root on sd0d type 4.2
[diags/configs]
root on: sd1f		[ mount root on sd1f ]
root filesystem type: 4.2
root on sd1f type 4.2
swap on: sd0b
swap filesystem type: spec
swap on sd0b type spec
dump on sd0b type spec offset 0xd3800
#

I could see potentially a way to "force" root to mount the FS on which
init resides:

	init is ...where? sd(0,0,4)/init
	mounting sd0e as /.INIT
	calling /.INIT/init

Or something.  Again probably more complexity than it's really worth,
and on that rare occasion it's probably easier to just re-install init
from the installation medium.
	
 * 
 *  > 	* If something goes wrong with init (i.e. it dies) it should detect
 *  > 	  that somehow the exec failed and move on to the next one.
 *  > 
 *  > The first one is a bit more flexible.  I don't see that it would be all
 *  > that hard to implement.  The first one is also more useful in the case that
 *  > init simply hangs.
 * 
 * --------------------------------------------------------------------------
 * Jason R. Thorpe                                       thorpej@nas.nasa.gov
 * NASA Ames Research Center                               Home: 408.866.1912
 * NAS: M/S 258-6                                          Work: 415.604.0935
 * Moffett Field, CA 94035                                Pager: 415.428.6939
 * 
 */

#undef AUTHOR	/* "thorpej@nas.nasa.gov (Jason Thorpe)" */




				--*greywolf;
--
People who cannot be persuaded to use turn signals or ashtrays while driving
should not be permitted to drive.