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

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?

kre