> 
> So, where should the bootparamd and bootp client code go?
> 
> Gordon W. Ross  		Mercury Computer Systems
> gwr@mc.com      		199 Riverneck Road
> 508-256-1300			Chelmsford, MA 01824-2820

the net-2/4.4 diskless implementation works as follows:
	bootstrap program does whatever is necessary to fetch kernel,
		fill in nfsdiskless structure w/server addresses, nfs file
		handles, client ip address, etc.
	nfs_mountroot() uses the previously initialized addresses
	and file handles to mount root/swap.

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().

advantages:
	you can strip your kernels :)
	bootstrapping program doesn't have to understand symbol table
	your bootstrap program can do something awful (like tftp)
		if you don't want to implement nfs (see libnetboot)
	source of kernel does not inherently imply root/swap source.
		maybe easier to do dataless.
	boot -a can  do the right thing.

some notes:
	kernel rpc implementation is tiny, and currently pretty
		stupid.  would need re-work if to be used for lock
		manager (ala sun) stuff.
	bootparam adds very little in terms of code/data size over
		just doing the file handle stuff that gordon's orignal
		work did.

your thoughts?

later,
Adam Glass

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