Subject: Re: 64-bit daddr_t problems with libsa
To: Robert Elz <kre@munnari.OZ.AU>
From: Simon Burge <firstname.lastname@example.org>
Date: 02/02/2003 13:32:31
Robert Elz wrote:
> Date: Fri, 31 Jan 2003 15:05:49 +1100
> From: Simon Burge <email@example.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 Burge <firstname.lastname@example.org>
NetBSD Support and Service: http://www.wasabisystems.com/