public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Christoph Hellwig <hch@lst.de>, xfs@oss.sgi.com
Subject: Re: [PATCH 09/21] implement generic xfs_btree_increment
Date: Fri, 1 Aug 2008 21:40:00 +0200	[thread overview]
Message-ID: <20080801194000.GC1263@lst.de> (raw)
In-Reply-To: <20080730020645.GJ13395@disturbed>

On Wed, Jul 30, 2008 at 12:06:45PM +1000, Dave Chinner wrote:
> > +int xfs_btree_increment(struct xfs_btree_cur *, int, int *);
> 
> I think for these interfaces it woul dbe better to include
> variable names in the prototypes. i.e.:
> 
> int xfs_btree_increment(struct xfs_btree_cur *cur, int level, int *stat);

Well, all this and much more is documented at the implementation site,
so I'd avoid this churn.  If there are strong feelings for it I
can change the prototypes.

> Can kill the else there:
> 
> 	if (cur->bc_flags & XFS_BTREE_LONG_PTRS)
> 		return be64_to_cpu(ptr->l) == NULLFSBLOCK;
> 	return be32_to_cpu(ptr->s) == NULLAGBLOCK;

Normally I'd agree with you, but for the short/long pointer case the
if else make the symmetry of the code clear and thus is IMHO better
readable.

> > +			ptr->s = block->bb_u.s.bb_rightsib;
> > +		else
> > +			ptr->s = block->bb_u.s.bb_leftsib;
> > +	}
> > +}
> 
> Should we use trinary notation for this? i.e:

I find the if else much easier to read.

> Hmmm - if xfs_btree_check_block() returns an error, we won't release
> the buffer in the error handling path. While this may not be a
> problem right now (as the only error is EFSCORRUPTED) we want to be
> able to recover from errors here in the future so we should really
> exit cleanly form this function....

Fixed.

> Would it be better here to explicitly test this rather than assert?
> ie.:
> 
> 	if (lev == cur->bc_nlevels) {
> 		if (cur->bc_flags & XFS_BTREE_ROOT_IN_INODE)
> 			goto out0;
> 		ASSERT(0);
> 		error = EFSCORRUPTED;
> 		goto error0;
> 	}
> 
> So that we get an explicit error reported in the production systems
> rather than carrying on and dying a horrible death somewhere else....

Yes, this is much better.  But we're getting on a slipperly slope here
to introduce too many improvements.  For the initial patches I'd like
to stay as close as possible to the old btree implementations.

Anyway, this change is trivial enough and I've added it.

  reply	other threads:[~2008-08-01 19:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-29 19:30 [PATCH 09/21] implement generic xfs_btree_increment Christoph Hellwig
2008-07-30  2:06 ` Dave Chinner
2008-08-01 19:40   ` Christoph Hellwig [this message]
2008-08-02  0:35     ` Dave Chinner

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=20080801194000.GC1263@lst.de \
    --to=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