Subject: Re: bootp
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
List: tech-kern
Date: 09/04/1995 15:52:23
> Ideally, what I'd like is to have an nfs_boot.c that understands both 
> rarp/bootparams _and_ bootp transparently, without having to set some 
> sort of compile-time option.

it seems that doing this right would be a bit more complicated...  8-)

specs like:

# any known FS on sd0
config		netbsd	root on sd0 swap on sd0
# a FFS on sd0
config		netbsd	root on sd0:ffs swap on sd0
# a LFS on sd0
config		netbsd	root on sd0:lfs swap on sd0
# etc

# root on nfs, found via rarp or bootp
config		netbsd	root on nfs swap on nfs
# root on nfs, rarp only
config		netbsd	root on nfs:rarp swap on nfs
# root on nfs, bootp only
config		netbsd	root on nfs:bootp swap on nfs

might be appropriate etc, or perhaps something a bit 'stranger', e.g.:

# root on from network using all known netboot tools
config		netbsd	root on net swap on net
# root on network device le0, any info-finding proto, any network FS
config		netbsd	root on net:le0 swap on net
# root on network device de0, any info-finding proto, any network FS
config		netbsd	root on net:de0 swap on net
# root on any network device, find boot info with rarp, any network FS
config		netbsd	root on net:rarp swap on net
# root on any network device, find boot info with bootp, any network FS
config		netbsd	root on net:bootp swap on net
# root on any network device, any info-finding proto, use NFS
config		netbsd	root on net:nfs swap on net
# root on any network device, any info-finding proto, use NFSv3
config		netbsd	root on net:nfsv3 swap on net
# root on network device le0, find boot info with rarp, use NFS
config		netbsd	root on net:le0:rarp:nfs swap on net
# etc.


just because the code should be able to work without a compile-time
option doesn't mean that one shouldn't be able to specify things
fully...

note that using a syntax like the one proposed above also solves the
problems of what to do for:
	(1) disk booting from alternate file system types, and
	(2) RB_askname name specification.
though it's not clear that the syntax is wonderful.

for instance, it seems that, given the way 'net' devices are named,
above, it would be reasonable to name disk devices:

	root on disk
	root on disk:sd0
	root on disk:ufs
	root on disk:ufs:sd0

etc. which then gives one generic 'diskful' booting, and, say:

	root on unknown

for generic booting.


note that in time, the 'swap on' specs should go away, so making them
pretty is moot.


chris