On Tue, 4 Jun 2002, Trevin Beattie wrote:

> At 08:16 PM 6/3/2002 -0700, Chuck Silvers wrote:
> >
> >as for FFS, I think the only place it has a problem is in its usage of
> >the fs_fsbtodb field in the superblock.  code that uses this field is
> >attempting to convert from a fragment size to the units of b_blkno,
> >so such code should really just compute the desired value
> >	(fs->fs_fshift - DEV_BSHIFT)
> >rather than using the value in the superblock.
>
> As I understand it then, your suggestion is to replace every instance of
> fs->fsbtodb, fsbtodb(), and dbtofsb() with the above equation.  That would
> certainly be much clearer than the way it is now (since the very definition
> of "db" is still unsettled).

Well, that's been my suggestion. :-)

> After fixing the kernel, what would we do with the unused fsbtodb and
> dbtofsb macros?  Define them in terms of sectors?  Deprecate them?  Replace
> them with something that issues a compiler error?  It seems to me that
> fs_fsbtodb should at least be deprecated, since its intended purpose can
> more reliably be derived from fs_fshift.

Either:

1) we lie and just put the fs_fsift - DEV_BSHIFT in fs_fstodb *in the
kernel* (we play tricks so that the written superblock retains the
original one). Keeps code divergence down. Disadvantage is that we have to
inspect every use when importing updates to see if they really mean
sectors.

2) We make a new pair of macros and put fs_fsift - DEV_BSHIFT in it.
Advantage is it makes importing code easy, disadvantage is it generates
lots of diffs. Since we are tracking other code bases, this choice might
be quite poor.

Take care,

Bill