Date: Mon, 21 Apr 2003 23:44:40 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: David Schultz <das@freebsd.org> Cc: current@freebsd.org Subject: Re: HEADS UP: UFS2 now the default creation type on 5.0-CURRENT Message-ID: <20030421231756.H11214@gamplex.bde.org> In-Reply-To: <20030421102341.GA3482@HAL9000.homeunix.com> References: <20030420192319.GB4963@HAL9000.homeunix.com> <Pine.NEB.3.96L.1030420174551.16891t-100000@fledge.watson.org> <20030421102341.GA3482@HAL9000.homeunix.com>
index | next in thread | previous in thread | raw e-mail
On Mon, 21 Apr 2003, David Schultz wrote: > The cgbase hack should only limit the size of the filesystem, not > the disk location. It occurs to me that with a little more > hackery, we can avoid the limitation entirely. If we revert to > the 64-bit cgbase() and un-inline it, boot2 goes from 19 bytes > available to -9 bytes. Add a kludge to factor out a few 64-bit > multiply-adds and we're back to 3 bytes available. (I'm sure > there are cleaner ways to save 9 bytes.) An untested unpolished > diff follows. I played with similar changes, but didn't finish them. > Index: ufsread.c > =================================================================== > RCS file: /cvs/src/sys/boot/common/ufsread.c,v > retrieving revision 1.11 > diff -u -r1.11 ufsread.c > --- ufsread.c 25 Feb 2003 00:10:20 -0000 1.11 > +++ ufsread.c 21 Apr 2003 10:10:01 -0000 > ... > @@ -47,11 +59,11 @@ > ... > -#define FS_TO_VBA(fs, fsb, off) (fsbtodb(fs, fsb) + \ > - ((off) / VBLKSIZE) * DBPERVBLK) > +#define FS_TO_VBA(fs, fsb, off) ma((off) / VBLKSIZE, DBPERVBLK, \ > + fsbtodb((fs), (fsb))) The division by VBLKSIZE should probably be a shift. ufsread.c has VBLKSHIFT and uses it for all multiplications and divisions by VBLKSIZE except this one. gcc can't optimize to just a shift since all the types are signed and C99 specifies that division of negative integers by positive ones has the usual hardware brokenness. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030421231756.H11214>