On Fri, Nov 23, 2012 at 07:40:15AM -0500, Christoph Hellwig wrote:
> On Mon, Nov 12, 2012 at 10:53:58PM +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> >
> > Factor xfs_btree_init_block() to be independent of the btree cursor,
> > and use the function to initialise btree blocks in the growfs code.
> > This makes adding support for different format btree blocks simple.
> >
> > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> > ---
> > fs/xfs/xfs_btree.c | 33 ++++++++++++++++++++++++---------
> > fs/xfs/xfs_btree.h | 11 +++++++++++
> > fs/xfs/xfs_fsops.c | 37 +++++++++++++------------------------
> > 3 files changed, 48 insertions(+), 33 deletions(-)
> >
> > diff --git a/fs/xfs/xfs_btree.c b/fs/xfs/xfs_btree.c
> > index e53e317..121ea99 100644
> > --- a/fs/xfs/xfs_btree.c
> > +++ b/fs/xfs/xfs_btree.c
> > @@ -853,18 +853,22 @@ xfs_btree_set_sibling(
> > }
> > }
> >
> > -STATIC void
> > +void
> > xfs_btree_init_block(
> > - struct xfs_btree_cur *cur,
> > - int level,
> > - int numrecs,
> > - struct xfs_btree_block *new) /* new block */
> > + struct xfs_mount *mp,
> > + struct xfs_buf *bp,
>
> Do we need the mount argument here? bp->b_mount should always
> be initialized.
Possible.
> > + __u32 magic,
> > + __u16 level,
> > + __u16 numrecs,
> > + unsigned int flags)
> > {
> > - new->bb_magic = cpu_to_be32(xfs_magics[cur->bc_btnum]);
> > + struct xfs_btree_block *new = XFS_BUF_TO_BLOCK(bp);
>
> Any reaosn not to pass the btree_block directly instead of the buffer?
CRC additions require the block number to be put into the structure,
so we need to pass the buffer.
>
> > +STATIC void
> > +xfs_btree_init_block_cur(
> > + struct xfs_btree_cur *cur,
> > + int level,
> > + int numrecs,
> > + struct xfs_buf *bp)
> > +{
> > + xfs_btree_init_block(cur->bc_mp, bp, xfs_magics[cur->bc_btnum],
> > + level, numrecs, cur->bc_flags);
>
> I'd scrapt this helper.
I only used it to avoid changing existing code. I can remove it when
CRCs are introduced if you want, as this touches all this code
again.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|