From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@lst.de>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 5/6] always use struct xfs_btree_block instead of short / longform structures
Date: Tue, 16 Sep 2008 16:26:16 +1000 [thread overview]
Message-ID: <20080916062616.GY5811@disturbed> (raw)
In-Reply-To: <20080915004657.GF12213@lst.de>
On Mon, Sep 15, 2008 at 02:46:57AM +0200, Christoph Hellwig wrote:
> Always use the generic xfs_btree_block type instead of the short / long
> structures. Add XFS_BTREE_SBLOCK_LEN / XFS_BTREE_LBLOCK_LEN defines for
> the length of a short / long form block. The rationale for this is that
> we will grow more btree block header variants to support CRCs and other
> RAS information, and always accessing them through the same datatype
> with unions for the short / long form pointers makes implementing this
> much easier.
.......
> @@ -382,16 +382,16 @@ xfs_alloc_fixup_trees(
> }
> #ifdef DEBUG
> {
> - xfs_alloc_block_t *bnoblock;
> - xfs_alloc_block_t *cntblock;
> + struct xfs_btree_block *bnoblock;
> + struct xfs_btree_block *cntblock;
Only need one tab there?
> +
> + if (bno_cur->bc_nlevels == 1 && cnt_cur->bc_nlevels == 1) {
> + bnoblock = XFS_BUF_TO_BLOCK(bno_cur->bc_bufs[0]);
> + cntblock = XFS_BUF_TO_BLOCK(cnt_cur->bc_bufs[0]);
>
> - if (bno_cur->bc_nlevels == 1 &&
> - cnt_cur->bc_nlevels == 1) {
> - bnoblock = XFS_BUF_TO_ALLOC_BLOCK(bno_cur->bc_bufs[0]);
> - cntblock = XFS_BUF_TO_ALLOC_BLOCK(cnt_cur->bc_bufs[0]);
> XFS_WANT_CORRUPTED_RETURN(
> - be16_to_cpu(bnoblock->bb_numrecs) ==
> - be16_to_cpu(cntblock->bb_numrecs));
> + bnoblock->bb_numrecs ==
> + cntblock->bb_numrecs);
The comparison could probably be made one line....
> @@ -77,24 +72,32 @@ typedef struct xfs_btree_sblock xfs_allo
> #define XFS_CNT_BLOCK(mp) ((xfs_agblock_t)(XFS_BNO_BLOCK(mp) + 1))
>
> /*
> + * Btree block header size depends on a superblock flag.
> + *
> + * (not quite yet, but soon)
> + */
> +#define XFS_ALLOC_BLOCK_LEN(mp) XFS_BTREE_SBLOCK_LEN
> +
> +/*
> * Record, key, and pointer address macros for btree blocks.
> + * (note that some of these may appear unused, but they are used in userspace)
Shouldn't that comment go in one of the previous patches?
(and others)
Otherwise looks ok....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2008-09-16 6:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-15 0:46 [PATCH 5/6] always use struct xfs_btree_block instead of short / longform structures Christoph Hellwig
2008-09-16 6:26 ` Dave Chinner [this message]
2008-09-16 17:31 ` Christoph Hellwig
2008-09-17 0:59 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2008-09-22 11:06 Christoph Hellwig
2008-10-01 15:22 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080916062616.GY5811@disturbed \
--to=david@fromorbit.com \
--cc=hch@lst.de \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox