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

My architecture is more like the first of these two. Actually, I don't think
that the net-2 implementation did support the filling of the nfsdiskless
structure by the bootstrap program. Do you have other info?

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

Most of the disadvantages of the first solution could easily be overcome by
including a pointer in locore to the nfsdiskless structure. This is what my
netboot code expects. You don't have to include symbols or symbol table
interpretation in the boot program.

Implementing tftp is a lot more work than implementing nfs, if you already
have a working rpc/xdr layer in the bootstrap program. And you need this
latter anyway, if you support bootparam.

I agree though, that boot -a can only be supported by including this stuff
in the kernel, since you could, for example, load the kernel from the disk
and use nfs for root and/or swap.

IMHO, this should, however be included only in the generic kernel.

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

As far as I know, the lock manager stuff doesn't to any rpc stuff in the
kernel. It's all user level code, which does locking on behalf of the remote
client (with some extension to the locking system call).

--
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) +49-228-985800

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