From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A3DD4276045 for ; Mon, 15 Sep 2025 20:53:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757969613; cv=none; b=SoV/vQrptx5YVDSIfsznMlVe061gaItDYah/ahJNTZ8yYwDu4DazNVRZL9fjRmH9X6R/6Rb1Ubd3Q1wf9dnjWuXd7KGChKuc2f6gRpuaDm49UqzcraYg/FYnq54WYMCkwN+jawqooV7So82mFeu+0ezYTnuhjUHpCJSwqrPSxYY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757969613; c=relaxed/simple; bh=1pue4g5spioZohCgIsAsTzDGob1ESvrZlb4/evacEwE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eD4aRW6VYFisPEn3cEy8tkqjSTCnnrwgP7WikdwHGcCmPqCnJQ1rHq6C7SdrxbPO4+S+rp7GKUcFTa/Y7VXHJ3CiGyBeSB0SNoeWdm6Ra671fYLF8eZoMMcgaRNfAgWlFpKPVBlNtXVm7OMNPPp/JU93PSxTse+G252SgsdnyfM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id 7F77C68AA6; Mon, 15 Sep 2025 22:53:27 +0200 (CEST) Date: Mon, 15 Sep 2025 22:53:27 +0200 From: Christoph Hellwig To: "Darrick J. Wong" Cc: Christoph Hellwig , Carlos Maiolino , linux-xfs@vger.kernel.org Subject: Re: [PATCH 5/6] xfs: centralize error tag definitions Message-ID: <20250915205327.GD5650@lst.de> References: <20250915133104.161037-1-hch@lst.de> <20250915133104.161037-6-hch@lst.de> <20250915191001.GX8096@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250915191001.GX8096@frogsfrogsfrogs> User-Agent: Mutt/1.5.17 (2007-11-01) 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 :) > 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. > > Also sorta wondering if for cleanliness this ought to be: > > #ifdef XFS_ERRTAG > # define XFS_ERRTAGS \ > > #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.