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.
>
>
next prev parent 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