All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Cc: Bill O'Donnell <bodonnel@redhat.com>,
	chandan.babu@oracle.com, linux-xfs@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Abaci Robot <abaci@linux.alibaba.com>
Subject: Re: [PATCH] xfs: Remove unused function
Date: Tue, 7 Nov 2023 12:44:05 -0800	[thread overview]
Message-ID: <20231107204405.GP1205143@frogsfrogsfrogs> (raw)
In-Reply-To: <ZUqPdhc4RQxL8TVB@redhat.com>

On Tue, Nov 07, 2023 at 01:26:46PM -0600, Bill O'Donnell wrote:
> On Fri, Nov 03, 2023 at 03:30:40PM +0800, Jiapeng Chong wrote:
> > The function are defined in the bitmap.c file, but not called
> > elsewhere, so delete the unused function.
> > 
> > fs/xfs/scrub/bitmap.c:55:1: warning: unused function 'xbitmap_tree_iter_next'.
> > 
> > Reported-by: Abaci Robot <abaci@linux.alibaba.com>
> > Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7137
> > Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
> 
> Makes sense.
> Reviewed-by: Bill O'Donnell <bodonnel@redhat.com>

I disagree -- I added redundant forward declarations here so I wouldn't
have to go digging through the 150LOC definition of INTERVAL_TREE_DEFINE
to figure out what helper functions were actually being defined by the
macro.  They'll trigger compiler errors if the definition of
INTERVAL_TREE_DEFINE ever drifts away from my understanding of it at the
time I wrote the code.

--D

> 
> 
> > ---
> >  fs/xfs/scrub/bitmap.c | 4 ----
> >  1 file changed, 4 deletions(-)
> > 
> > diff --git a/fs/xfs/scrub/bitmap.c b/fs/xfs/scrub/bitmap.c
> > index e0c89a9a0ca0..ba4b18e40faa 100644
> > --- a/fs/xfs/scrub/bitmap.c
> > +++ b/fs/xfs/scrub/bitmap.c
> > @@ -48,10 +48,6 @@ static inline struct xbitmap_node *
> >  xbitmap_tree_iter_first(struct rb_root_cached *root, uint64_t start,
> >  			uint64_t last);
> >  
> > -static inline struct xbitmap_node *
> > -xbitmap_tree_iter_next(struct xbitmap_node *node, uint64_t start,
> > -		       uint64_t last);
> > -
> >  INTERVAL_TREE_DEFINE(struct xbitmap_node, bn_rbnode, uint64_t,
> >  		__bn_subtree_last, START, LAST, static inline, xbitmap_tree)
> >  
> > -- 
> > 2.20.1.7.g153144c
> > 
> 

  reply	other threads:[~2023-11-07 20:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-03  7:30 [PATCH] xfs: Remove unused function Jiapeng Chong
2023-11-07 19:26 ` Bill O'Donnell
2023-11-07 20:44   ` Darrick J. Wong [this message]
2023-11-11 15:39     ` Eric Sandeen

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=20231107204405.GP1205143@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=abaci@linux.alibaba.com \
    --cc=bodonnel@redhat.com \
    --cc=chandan.babu@oracle.com \
    --cc=jiapeng.chong@linux.alibaba.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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.