Subject: Re: boot code bloat with 64bit sector numbers
From: David Laight <email@example.com>
Date: 04/10/2003 10:27:29
On Thu, Apr 10, 2003 at 05:48:53PM +1000, Simon Burge wrote:
> David Laight wrote:
> > When I try to compile some of the boot code with a 64bit daddr_t
> > I find that it exceeds the available space.
> Which architecture is this on and what is the size limit?
These is the i386 bootxx code I'm looking at.
The limit is about 7.5k including the pbr and label - maybe I could
go to 8k, but it isn't clear that a single bios read can span a track
boundary, which wuld be necessary for 1.2M floppies (only 15 sectors
> > The only place it seems to be used is in the filesystem code where
> > it works out which of the indirect blocks needs to be inspected.
> > For ufs the divide/remainder can definitely be replaced by a shift/mask
> > (see diff below).
> When I was trying to squeeze the pmax and alpha (and maybe some others?)
> bootblocks down to size with the introduction of 64 bit daddr_t the
> shift/mask method still required more space than just using 32-bit
> daddr_t's - that's why I made small daddr_t an option.
But it does save a lot of space, a few other tweaks might get it all to
fit. One option might be to only allow the 1st level indirects.
(limits you to 8k/4 * 8k = 16Mb files - or 4Mb with 4k blocks,
enough for /boot, maybe even enough for the kernel).
> I still haven't had a chance to get these architecture's bootblocks
> down to size with ufsv2 yet.
I'm 99% of the way through the code to build a ufs2 only boot code.
(the shared one is/was only used by the i386 biosboot).
The ufs2 version is much the same size as ufs1.
I'm trying to get the lfs code to build from the same source file
- I hate duplicated code.
David Laight: firstname.lastname@example.org