I just finished moving, time to hop back in and reply to this
with my ideas. (then sleep :-)


>my/theo? architecture:
>	bootstrap program does whetaver is necessary to fetch kernel.
>	nfs_mountroot() called revarp_whoami() to get client address,
>		calls bootparam_whoami() and bootparam_getfile() to
>		get root (swap) server addr and root (swap) pathname.
>		then it calls nfs_getfh() on the root (swap) pathname.
>		Then it does the normal nfs_mountroot() activities.
>		Actually most of the above stuff is under nfs_boot()
>		which is called by nfs_mountroot().

well, let's give Sun some credit :-)

i am a fan of Sun's network boot path. basically it goes like
this;

- bootrom rarps to get it's IP address, say it finds it to be
  123.45.67.89.
  tftp is used to fetch the file "123.45.67.89.SUN3", which
  we then execute. this file is the secondary boot loader.
  (the bootrom can be very small -- i've written a lance-based
  bootrom that is under 8K of m68k c/assembly code.)
- the secondary boot loader is more complicated, and since it
  isn't in the rom can be quite a bit larger. it can use any
  method it wants to
	(1) find the root/swap filesystems
	    (a) bootparams (my favorite)
	    (b) bootp
	    (c) say.. a file in the tftp directory?
	(2) load the kernel
	    (a) use tftp (i think this is bad)
	    (b) use nfs (much preferred)
  in any case the secondary server generally will rarp again.
  (i think it does for the sun3, but doesn't for the sparc?)

  you can use different secondary boot loaders for different
  modes of operation.

- when the kernel comes up, it uses rarp/bootparams once again to
  find out where what's going on, as described above by Adam.

notes:
- why do you not want to tftp your kernel? well, most people
  run tftpd in secure mode, ie. chroot'd to /tftpboot. if it
  is chroot'd you cannot use symbolic links to the file
  /export/clienta/root/netbsd. you must use a hard link. but if
  /export happens to be a different filesystem... you're outa
  luck.

  you do want the file "/netbsd" in the client's root filesystem
  to be the same file as it booted from. otherwise ps/w/vmstat/iostat
  & friends don't work.

  this is why sun uses NFS to fetch the kernel. the secondary
  bootblock is smart (and can be large enough) to load the kernel
  over NFS, from the exact same file.

>	bootstrapping program doesn't have to understand symbol table

this is a large win.

>	your bootstrap program can do something awful (like tftp)
>		if you don't want to implement nfs (see libnetboot)

as said above, nfs is a much cleaner way to fetch the kernel.

>	boot -a can  do the right thing.

boot -a can do the right thing with IP/path specifications.. it cannot
handle hostnames. I have a vague memory that Wolfgang's bootrom code
had BIND in it... that's not a very good idea though.

------------------------------------------------------------------------------