From: Christoph Hellwig <hch@lst.de>
To: Carlos Maiolino <cem@kernel.org>
Cc: linux-xfs@vger.kernel.org
Subject: [PATCH 03/15] xfs: remove the xfs_extent_t typedef
Date: Mon, 15 Sep 2025 06:26:53 -0700 [thread overview]
Message-ID: <20250915132709.160247-4-hch@lst.de> (raw)
In-Reply-To: <20250915132709.160247-1-hch@lst.de>
There are almost no users of the typedef left, kill it and switch the
remaining users to use the underlying struct.
Also fix up the comment about the struct xfs_extent definition to be
correct and read more easily.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/xfs/libxfs/xfs_log_format.h | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_log_format.h b/fs/xfs/libxfs/xfs_log_format.h
index 8f208e93ec3b..2cfbadae3f53 100644
--- a/fs/xfs/libxfs/xfs_log_format.h
+++ b/fs/xfs/libxfs/xfs_log_format.h
@@ -596,16 +596,17 @@ xfs_blft_from_flags(struct xfs_buf_log_format *blf)
/*
* EFI/EFD log format definitions
*/
-typedef struct xfs_extent {
+struct xfs_extent {
xfs_fsblock_t ext_start;
xfs_extlen_t ext_len;
-} xfs_extent_t;
+};
/*
- * Since an xfs_extent_t has types (start:64, len: 32)
- * there are different alignments on 32 bit and 64 bit kernels.
- * So we provide the different variants for use by a
- * conversion routine.
+ * Since the structures in struct xfs_extent add up to 96 bytes, it has
+ * different alignments on i386 vs all other architectures, because i386
+ * does not pad structures to their natural alignment.
+ *
+ * Provide the different variants for use by a conversion routine.
*/
typedef struct xfs_extent_32 {
uint64_t ext_start;
@@ -628,7 +629,7 @@ typedef struct xfs_efi_log_format {
uint16_t efi_size; /* size of this item */
uint32_t efi_nextents; /* # extents to free */
uint64_t efi_id; /* efi identifier */
- xfs_extent_t efi_extents[]; /* array of extents to free */
+ struct xfs_extent efi_extents[]; /* array of extents to free */
} xfs_efi_log_format_t;
static inline size_t
@@ -681,7 +682,7 @@ typedef struct xfs_efd_log_format {
uint16_t efd_size; /* size of this item */
uint32_t efd_nextents; /* # of extents freed */
uint64_t efd_efi_id; /* id of corresponding efi */
- xfs_extent_t efd_extents[]; /* array of extents freed */
+ struct xfs_extent efd_extents[]; /* array of extents freed */
} xfs_efd_log_format_t;
static inline size_t
--
2.47.2
next prev parent reply other threads:[~2025-09-15 13:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-15 13:26 remove most typedefs from xfs_log_format.h Christoph Hellwig
2025-09-15 13:26 ` [PATCH 01/15] xfs: remove the xlog_op_header_t typedef Christoph Hellwig
2025-09-15 13:26 ` [PATCH 02/15] xfs: remove the xfs_trans_header_t typedef Christoph Hellwig
2025-09-15 13:26 ` Christoph Hellwig [this message]
2025-09-15 13:26 ` [PATCH 04/15] xfs: remove the xfs_extent32_t typedef Christoph Hellwig
2025-09-15 13:26 ` [PATCH 05/15] xfs: remove the xfs_extent64_t typedef Christoph Hellwig
2025-09-15 13:26 ` [PATCH 06/15] xfs: remove the xfs_efi_log_format_t typedef Christoph Hellwig
2025-09-15 13:26 ` [PATCH 07/15] xfs: remove the xfs_efi_log_format_32_t typedef Christoph Hellwig
2025-09-15 13:26 ` [PATCH 08/15] xfs: remove the xfs_efi_log_format_64_t typedef Christoph Hellwig
2025-09-15 13:26 ` [PATCH 09/15] xfs: remove the xfs_efd_log_format_t typedef Christoph Hellwig
2025-09-15 13:27 ` [PATCH 10/15] xfs: remove the unused xfs_efd_log_format_32_t typedef Christoph Hellwig
2025-09-15 13:27 ` [PATCH 11/15] xfs: remove the unused xfs_efd_log_format_64_t typedef Christoph Hellwig
2025-09-15 13:27 ` [PATCH 12/15] xfs: remove the unused xfs_buf_log_format_t typedef Christoph Hellwig
2025-09-15 13:27 ` [PATCH 13/15] xfs: remove the unused xfs_dq_logformat_t typedef Christoph Hellwig
2025-09-15 13:27 ` [PATCH 14/15] xfs: remove the unused xfs_qoff_logformat_t typedef Christoph Hellwig
2025-09-15 13:27 ` [PATCH 15/15] xfs: remove the unused xfs_log_iovec_t typedef Christoph Hellwig
2025-09-15 18:29 ` remove most typedefs from xfs_log_format.h Darrick J. Wong
2025-09-16 11:34 ` Carlos Maiolino
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=20250915132709.160247-4-hch@lst.de \
--to=hch@lst.de \
--cc=cem@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox