All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Nikolay Borisov <nborisov@suse.com>
Cc: linux-xfs@vger.kernel.org, darrick.wong@oracle.com
Subject: Re: [PATCH 3/3] xfs: Opencode and remove DEFINE_SINGLE_BUF_MAP
Date: Tue, 13 Aug 2019 07:57:45 -0400	[thread overview]
Message-ID: <20190813115745.GC37069@bfoster> (raw)
In-Reply-To: <20190813090306.31278-4-nborisov@suse.com>

On Tue, Aug 13, 2019 at 12:03:06PM +0300, Nikolay Borisov wrote:
> This macro encodes a trivial struct initializations, just open code it.
> 
> Signed-off-by: Nikolay Borisov <nborisov@suse.com>
> ---

Seems fine:

Reviewed-by: Brian Foster <bfoster@redhat.com>

What might be more interesting is to audit the cases where nmap is
always 1 and see if we can start eliminating some of this code where it
isn't needed. For example, it looks xfs_buf_readahead_map() only ever
uses nmap == 1. Can we pass a block/len directly there and push the
map/nmap parameters further down the stack? FWIW, I also see several
functions on a quick glance (xfs_dabuf_map(), xfs_buf_map_from_irec())
that take map/nmaps params, assert that nmaps == 1 yet still have
iteration code for nmap > 1 cases.

>  fs/xfs/xfs_buf.c   | 4 ++--
>  fs/xfs/xfs_buf.h   | 9 +++------
>  fs/xfs/xfs_trans.h | 6 ++++--
>  3 files changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> index 99c66f80d7cc..389c5b590f11 100644
> --- a/fs/xfs/xfs_buf.c
> +++ b/fs/xfs/xfs_buf.c
> @@ -658,7 +658,7 @@ xfs_buf_incore(
>  {
>  	struct xfs_buf		*bp;
>  	int			error;
> -	DEFINE_SINGLE_BUF_MAP(map, blkno, numblks);
> +	struct xfs_buf_map map = { .bm_bn = blkno, .bm_len = numblks };
>  
>  	error = xfs_buf_find(target, &map, 1, flags, NULL, &bp);
>  	if (error)
> @@ -905,7 +905,7 @@ xfs_buf_get_uncached(
>  	unsigned long		page_count;
>  	int			error, i;
>  	struct xfs_buf		*bp;
> -	DEFINE_SINGLE_BUF_MAP(map, XFS_BUF_DADDR_NULL, numblks);
> +	struct xfs_buf_map map = { .bm_bn = XFS_BUF_DADDR_NULL, .bm_len = numblks };
>  
>  	/* flags might contain irrelevant bits, pass only what we care about */
>  	bp = _xfs_buf_alloc(target, &map, 1, flags & XBF_NO_IOACCT);
> diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h
> index ec7037284d62..548dfb0c6e27 100644
> --- a/fs/xfs/xfs_buf.h
> +++ b/fs/xfs/xfs_buf.h
> @@ -104,9 +104,6 @@ struct xfs_buf_map {
>  	int			bm_len;	/* size of I/O */
>  };
>  
> -#define DEFINE_SINGLE_BUF_MAP(map, blkno, numblk) \
> -	struct xfs_buf_map (map) = { .bm_bn = (blkno), .bm_len = (numblk) };
> -
>  struct xfs_buf_ops {
>  	char *name;
>  	union {
> @@ -209,7 +206,7 @@ xfs_buf_get(
>  	xfs_daddr_t		blkno,
>  	size_t			numblks)
>  {
> -	DEFINE_SINGLE_BUF_MAP(map, blkno, numblks);
> +	struct xfs_buf_map map = { .bm_bn = blkno, .bm_len = numblks };
>  	return xfs_buf_get_map(target, &map, 1, 0);
>  }
>  
> @@ -221,7 +218,7 @@ xfs_buf_read(
>  	xfs_buf_flags_t		flags,
>  	const struct xfs_buf_ops *ops)
>  {
> -	DEFINE_SINGLE_BUF_MAP(map, blkno, numblks);
> +	struct xfs_buf_map map = { .bm_bn = blkno, .bm_len = numblks };
>  	return xfs_buf_read_map(target, &map, 1, flags, ops);
>  }
>  
> @@ -232,7 +229,7 @@ xfs_buf_readahead(
>  	size_t			numblks,
>  	const struct xfs_buf_ops *ops)
>  {
> -	DEFINE_SINGLE_BUF_MAP(map, blkno, numblks);
> +	struct xfs_buf_map map = { .bm_bn = blkno, .bm_len = numblks };
>  	return xfs_buf_readahead_map(target, &map, 1, ops);
>  }
>  
> diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h
> index 64d7f171ebd3..8d6fce5c0320 100644
> --- a/fs/xfs/xfs_trans.h
> +++ b/fs/xfs/xfs_trans.h
> @@ -182,7 +182,8 @@ xfs_trans_get_buf(
>  	int			numblks,
>  	uint			flags)
>  {
> -	DEFINE_SINGLE_BUF_MAP(map, blkno, numblks);
> +	struct xfs_buf_map map = { .bm_bn = blkno, .bm_len = numblks };
> +
>  	return xfs_trans_get_buf_map(tp, target, &map, 1, flags);
>  }
>  
> @@ -205,7 +206,8 @@ xfs_trans_read_buf(
>  	struct xfs_buf		**bpp,
>  	const struct xfs_buf_ops *ops)
>  {
> -	DEFINE_SINGLE_BUF_MAP(map, blkno, numblks);
> +	struct xfs_buf_map map = { .bm_bn = blkno, .bm_len = numblks };
> +
>  	return xfs_trans_read_buf_map(mp, tp, target, &map, 1,
>  				      flags, bpp, ops);
>  }
> -- 
> 2.17.1
> 

  reply	other threads:[~2019-08-13 11:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-13  9:03 [PATCH 0/3] Minor cleanups Nikolay Borisov
2019-08-13  9:03 ` [PATCH 1/3] xfs: Use __xfs_buf_submit everywhere Nikolay Borisov
2019-08-13 11:55   ` Brian Foster
2019-08-13 12:06     ` Nikolay Borisov
2019-08-13 12:15       ` Nikolay Borisov
2019-08-13  9:03 ` [PATCH 2/3] xfs: Rename __xfs_buf_submit to xfs_buf_submit Nikolay Borisov
2019-08-13 11:56   ` Brian Foster
2019-08-14 10:14     ` Dave Chinner
2019-08-13  9:03 ` [PATCH 3/3] xfs: Opencode and remove DEFINE_SINGLE_BUF_MAP Nikolay Borisov
2019-08-13 11:57   ` Brian Foster [this message]
2019-08-14 10:23   ` 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=20190813115745.GC37069@bfoster \
    --to=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=nborisov@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.