> No objections, but why are the bootxx_ffs (and I presume the _lfs
> as well) using daddr_t at all?
> 
> That's not the data type that is in the filesystemsm ffs uses
> ufs_daddr_t when it wants to put a block number somewhere.  I assume
> (but haven't checked) that LFS is similar.

It will allow you to boot from a UFS filesystem that is beyond
1TB down the disk...

I do wonder whether the the following interface would be
enough for the boot code - which only ever nees to have
a single file open etc.

ufs_mount(...);	: read superblock etc
length = ufs_read_file(int inode, void *buffer, size_t buflen);
inode = ufs_scan_dir(char *name, void *buffer, size_t buflen)

To read /boot you would do:
	ufs_mount(...);
	len = ufs_read_file( 2 /* root inode */, load_tgt, ~0);
	inode = ufs_scan_dir("boot", load_tgt, len);
	ufs_read_file(inode, load_tgt, ~0);

	/* jump into image */
	call *(void (*)(void))load_tgt;

That ought to fit into almost no bytes at all.
Especially if you don't need support for double (or triple)
indirect blocks.

Could probably even get the i386 code to not need a sector/count
list....

	David

-- 
David Laight: david@l8s.co.uk