Robert Elz wrote:

>     Date:        Fri, 31 Jan 2003 15:05:49 +1100
>     From:        Simon Burge <simonb@wasabisystems.com>
>     Message-ID:  <20030131040549.6295653E7F@thoreau.thistledown.com.au>
> 
>   | No objections to this much?  At least this gets the bootblocks on the
>   | above machines working again.  We can worry about other space-saving
>   | ideas later on...
> 
> No objections [ ... ]

I've committed these changes now so that we at least have working
bootblocks on 3 or 4 platforms.

> [ ... ] but why are the bootxx_ffs (and I presume the _lfs
> as well) using daddr_t at all?

Indeed, one early idea I looked at was to make ufs.c use int32_t
everywhere and when/if we get large block number support adding a
ufs2.c (maybe using some CPP magick on ufs.c, I think the on-disk
inode changes too) that used int64_t for disk block addresses.
But ... (read on)

> 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.
> 
> daddr_t is the kernel's grand unification of all of the possible data
> types that might exist in different filesystems - the boot blocks don't
> need to be unified that way, there are already different ones for different
> filesystem types, and when we get a filesystem that has 64 bit (or 48 bit
> or something) on drive filesystems, we're going to need new boot blocks
> to handle it anyway.
> 
> So, rather than playing tricks with ifdef's in header files, wouldn't it
> be better to simply have things use the data types that actually match the
> data that they're accessing?

One problem is that we use daddr_t for one of the parameters to the
foo_strategy() routines.  Using a universal 32bit daddr_t results in a
smaller object file than just using int32_t for disk block fields and
variables in ufs.c (this on Alpha):

text    data    bss     dec     hex     filename
2720           0       0       2720    aa0     lib/sa/ufs.o (daddr_t=uint32_t)
2752           0       0       2752    ac0     lib/sa/ufs.o (use uint32_t)

I suspect this is lossage due to the daddr_t parameter in the strategy()
routines but haven't been able to verify that yet.

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/