Theo Deraadt asked if I had thought about adding booparamd support
to the kernel as well.  I'd like to hear peoples ideas about how
such functionality should be organized.  If this has all been hashed
out already, please point me to the relevant message archives.

So, to kick things off, here are my thoughts on where things might
be implemented:  (kernel vs. boot-program)

The current interface between the boot program and the kernel puts
most of the burden of boot-time info fetch on the boot program,
presumably with the rationale that things that are done only once
during boot should be done by a program that goes away so it does
not occupy memory.  In general I like this approach, but I think
it is reasonable to make an exception for the mountd RPCs because
doing these in the kernel makes the interface to the kernel so much
more friendly to either the boot program or to a user (boot -a).

I think the remaining boot-time information gathering burden might
still just as well remain the responsibility of the boot program,
at least for most systems.  Perhaps we should make exception for
Sun systems for compatibility.  I tried to make the nfs_callrpc
function reusable so it should not be hard to add bootparams RPC
support.  I wasn't sure how welcome all this new code would be.

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

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