Subject: Re: 64-bit daddr_t problems with libsa
To: Simon Burge <firstname.lastname@example.org>
From: Robert Elz <kre@munnari.OZ.AU>
Date: 02/03/2003 18:44:41
Date: Sun, 02 Feb 2003 13:32:31 +1100
From: Simon Burge <email@example.com>
| I've committed these changes now so that we at least have working
| bootblocks on 3 or 4 platforms.
| One problem is that we use daddr_t for one of the parameters to the
| foo_strategy() routines.
Yes, that is as it should be I think.
| 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):
That makes sense too - but are things really that critical that a 32
byte size difference matters that much? If so, how is UFS2 support ever
going to be added? That's going to require going back to bigger block
numbers everywhere... (and perhaps more).
(I mean "added" in the sense of being able to make a UFS2 (only) version, not
a version that could handle either, which would obviously be a blowout).
If the limit is that tight, then some alternate strategy for booting the
affected systems sounds as if it might be required (though what that might
be I'm not sure).