Linux XFS filesystem development
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Carlos Maiolino <cem@kernel.org>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 5/6] xfs: centralize error tag definitions
Date: Mon, 15 Sep 2025 16:37:55 -0700	[thread overview]
Message-ID: <20250915233755.GA8096@frogsfrogsfrogs> (raw)
In-Reply-To: <20250915205327.GD5650@lst.de>

On Mon, Sep 15, 2025 at 10:53:27PM +0200, Christoph Hellwig wrote:
> On Mon, Sep 15, 2025 at 12:10:01PM -0700, Darrick J. Wong wrote:
> > > -#ifndef __XFS_ERRORTAG_H_
> > > +#if !defined(__XFS_ERRORTAG_H_) || defined(XFS_ERRTAG)
> > 
> > Hrmm.  So now xfs_errortag.h has two uses: one where we just #include
> > it without defining XFS_ERRTAG, and we get the XFS_ERRTAG_* values?
> 
> Yes.
> 
> > and I guess a broken XFS_ERRTAGS that isn't fully defined?
> 
> Yes.  I wouldn't call it broken, just not usable :)

Heh. :)

> > And then you're allowed to #include it again, provided you enclose that
> > inside a #define XFS_ERRTAG and a user of an XFS_ERRTAGS symbol, in
> > which case it actually spits out a usable XFS_ERRTAGS?
> 
> Yes.
> 
> > That could be documented better.
> > 
> > "There are two ways to use this header file.  The first way is to
> > #include it bare, which will define all the XFS_ERRTAG_* error injection
> > knobs for use with the XFS_TEST_ERROR macro.  The second way is to
> > enclose the #include with a #define for an XFS_ERRTAG macro, in which
> > case the header will define an XFS_ERRTAGS macro that expands to one
> > XFS_ERRTAG use for each defined error injection knob."
> 
> I can add that.
> 
> > > +
> > > +#define XFS_ERRTAGS \
> > 
> > Do you need to #undef XFS_ERRTAGS here to prevent the W=XXX build and/or
> > static tools from whining about redefined macros?
> 
> XFS_ERRTAGS is redefined identically, which is allowed.  And we can't
> undef it here, because we use the definition in the .c files.  We could
> undef it after using it, but that feels a bit pointless.

Sorry, I should have spelled out what I meant explicitly:

#ifdef XFS_ERRTAG
# undef XFS_ERRTAGS
# define XFS_ERRTAGS \
<giant blob of error knobs>
#endif /* XFS_ERRTAG */

You undefine XFS_ERRAGS *before* redefining it, just to make it clear to
anyone reading the .h file that the exact definition of XFS_ERRTAGS in a
.c file can be fluid.

--D

> > 
> > Also sorta wondering if for cleanliness this ought to be:
> > 
> > #ifdef XFS_ERRTAG
> > # define XFS_ERRTAGS \
> > <giant table>
> > #endif /* XFS_ERRTAG */
> > 
> > To avoid cluttering up the macro namespace if the file #include'ing
> > xfs_errortag.h didn't define XFS_ERRTAG and doesn't actually want the
> > ERRTAGS expansion?
> 
> That does sound doable, let me give it a try.
> 
> 

  reply	other threads:[~2025-09-15 23:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-15 13:30 cleanup error tags Christoph Hellwig
2025-09-15 13:30 ` [PATCH 1/6] xfs: remove xfs_errortag_get Christoph Hellwig
2025-09-15 18:54   ` Darrick J. Wong
2025-09-15 13:30 ` [PATCH 2/6] xfs: remove xfs_errortag_set Christoph Hellwig
2025-09-15 18:54   ` Darrick J. Wong
2025-09-15 13:30 ` [PATCH 3/6] xfs: remove the expr argument to XFS_TEST_ERROR Christoph Hellwig
2025-09-15 18:55   ` Darrick J. Wong
2025-09-15 13:30 ` [PATCH 4/6] xfs: remove pointless externs in xfs_error.h Christoph Hellwig
2025-09-15 18:55   ` Darrick J. Wong
2025-09-15 13:30 ` [PATCH 5/6] xfs: centralize error tag definitions Christoph Hellwig
2025-09-15 19:10   ` Darrick J. Wong
2025-09-15 20:53     ` Christoph Hellwig
2025-09-15 23:37       ` Darrick J. Wong [this message]
2025-09-15 13:30 ` [PATCH 6/6] xfs: constify xfs_errortag_random_default Christoph Hellwig
2025-09-15 19:10   ` Darrick J. Wong
  -- strict thread matches above, loose matches on Subject: below --
2025-09-16 16:28 cleanup error tags v2 Christoph Hellwig
2025-09-16 16:28 ` [PATCH 5/6] xfs: centralize error tag definitions Christoph Hellwig
2025-09-16 16:38   ` Darrick J. Wong
2025-09-16 16:40     ` Christoph Hellwig
2025-09-16 16:46       ` Darrick J. Wong

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=20250915233755.GA8096@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=hch@lst.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox