public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Chandra Seetharaman <sekharan@us.ibm.com>
Cc: Alex Elder <aelder@sgi.com>, XFS Mailing List <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfs: replace bp->flags usage with predefined macros
Date: Wed, 29 Jun 2011 14:46:16 +1000	[thread overview]
Message-ID: <20110629044616.GB1026@dastard> (raw)
In-Reply-To: <1309308784.5505.6214.camel@chandra-lucid.beaverton.ibm.com>

On Tue, Jun 28, 2011 at 05:53:04PM -0700, Chandra Seetharaman wrote:
> Cleanup: Replace bp->flags usage with predefined macros.
> 
> Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com>

Christoph can correct me if I'm wrong, but I'm pretty sure his long term
direction is to remove the XFS_BUF_* macros completely.

Even so, in any new code we add or modify in xfs_buf.c we tend to
open code the flags. Hence the only code there that still uses the
XFS_BUF_* macros for manipulating flags are those we haven't needed
to touch for a long time....

> ---
> diff --git a/fs/xfs/linux-2.6/xfs_buf.c b/fs/xfs/linux-2.6/xfs_buf.c
> index 5e68099..8b24dc4 100644
> --- a/fs/xfs/linux-2.6/xfs_buf.c
> +++ b/fs/xfs/linux-2.6/xfs_buf.c
> @@ -470,7 +470,7 @@ _xfs_buf_find(
>  			 * continue searching to the right for an exact match.
>  			 */
>  			if (bp->b_buffer_length != range_length) {
> -				ASSERT(bp->b_flags & XBF_STALE);
> +				ASSERT(XFS_BUF_ISSTALE(bp));
>  				rbp = &(*rbp)->rb_right;
>  				continue;
>  			}
> @@ -516,7 +516,7 @@ found:
>  	 * it. We need to keep flags such as how we allocated the buffer memory
>  	 * intact here.
>  	 */
> -	if (bp->b_flags & XBF_STALE) {
> +	if (XFS_BUF_ISSTALE(bp)) {
>  		ASSERT((bp->b_flags & _XBF_DELWRI_Q) == 0);
>  		bp->b_flags &= XBF_MAPPED | _XBF_KMEM | _XBF_PAGES;
>  	}

And this code fragment is an example of why we are open coding the
flags checks: we do non-trivial open-coded flag manipulations
in many places, and hiding the fact that state is held in b_flags
makes it harder to read the code.

That is, the code as it stands in this case makes it obvious
that that if the buffer was stale, afterwards it is not stale
because the bit was cleared from b_flags. Using the macro hides the
fact that the stale state is held in b_flags and therefore cleared
by the conditional code and that the buffer is no longer stale...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-06-29  4:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-29  0:53 [PATCH] xfs: replace bp->flags usage with predefined macros Chandra Seetharaman
2011-06-29  4:46 ` Dave Chinner [this message]
2011-06-29  6:30   ` Christoph Hellwig
2011-06-29 20:33     ` Chandra Seetharaman
2011-06-29 21:58       ` Alex Elder
2011-06-29 22:02         ` Chandra Seetharaman

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=20110629044616.GB1026@dastard \
    --to=david@fromorbit.com \
    --cc=aelder@sgi.com \
    --cc=sekharan@us.ibm.com \
    --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