Skip to content

xfsdump: Ouchie! My bleeding eyes!

Dave Chinner linux-xfs 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest8 patches 8 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/8cleanup: get rid of ASSERTcommon/arch_xlate.c common/cldmgr.c common/cleanup.c +42 more+1362 -13195 replies
2/8build: don't rely on xfs/xfs.h to include necessary headerscommon/arch_xlate.c common/arch_xlate.h common/cldmgr.c +58 more+256 -180 replies
3/8cleanup: kill intgen_tcommon/cldmgr.c common/cldmgr.h common/content.h +55 more+872 -8720 replies
4/8cleanup: kill u_int*_t typescommon/content_inode.h common/drive.h common/drive_minrmt.c +32 more+319 -3140 replies
5/8cleanup: define a local xfs_ino_tcommon/types.h+2 -00 replies
6/8cleanup: use system uuid.h headerscommon/fs.c common/global.c common/inventory.c +16 more+19 -00 replies
7/8cleanup: move fold_t out of util.hcommon/mlog.c common/mlog.h common/types.h +2 more+56 -560 replies
8/8cleanup: Kill unnecessary xfs includescommon/arch_xlate.c common/arch_xlate.h common/cldmgr.c +34 more+79 -1090 replies

Reviews trailers per patch

1 of 8 patches has a Reviewed-by or Acked-by.

PatchBrian Foster
1/8A-b
2/8
3/8
4/8
5/8
6/8
7/8
8/8

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [PATCH 0/8] xfsdump: Ouchie! My bleeding eyes!

Hi folks,

Turns out that changes to exported XFS headers in xfsprogs v4.2.0 broke the xfsdump build. the XFS dump build was implicitly including the platform definitions calculated for the xfsprogs build and so removing them from the xfsprogs headers made xfsdump very unhappy.

I've spend the last couple of days dripping blood from my eyeballs all over my keyboard trying to clean up the mess a bit. This patch set fixes the build issue and tries to minimise the amount of XFS header inclusion across the xfsdump code base.

To this end:

1. remove xfsdump's use of ASSERT because the definition in the XFs headers overrode everything else. So the first patch is a global s/ASSERT/assert/, #include <assert.h> change.

2. fix the build issues. With the assert conflict out of the way, patch 2 includes all the bits xfsdump really needed from the xfsprogs platform defs. This is added to the include/config.h.in file, and this is then included across the code base.

3. xfs/jdm.h does "typedef int intgen_t;" for it's API. xfsdump uses it *everywhere* (~900 instances across the code base), yet everywhere it is used an "int" will sufficient and there's only a handful of jdm_* API calls anyway. Patch 3 is therefore s/intgen_t/int/g

4. why use uint*_t when you can use a random mix of types? Patch 4 is therefore s/u_int/uint/g

5. xfs_ino_t. Always going to be uint64_t. Use a local definition, not pull all of XFS into all of xfsdump just for a single typedef (patch 5).

6. Use <uuid/uuid.h>, not whatever hacked up uuid interface that you get from the XFS headers, which is not then used correctly because nothing uses the "platform_uuid_*()" abstraction the XFS headers provide. Clearly, xfsdump has only *ever* been compiled on Linux, as the build will break on BSD based platforms like Irix and FreeBSD. xfsdump is a Linux only source tree right now....

7. Yeah, lets put random stuff in a header file that is included all over the place that requires the XFS headers to be included. Patch 7 pulls out the bits used by logging/reporting and puts them in the logging/reporting source files.

8. Kill as many <xfs/xfs.h> and <xfs/jdm.h> includes as possible. Most of the files including them are now just missing system header includes and no longer need util.h, so patch 8 cleans up all that mess.

So, now the code base is a little bit cleaner, a lot less dependent on the xfsprogs header files, compiles cleanly on xfsprogs 3.2.x and 4.x releases, can easily have asserts build in or excluded (distro packages need to use "export DEBUG=-DNDEBUG" to exclude asserts), passes xfstests with asserts enabled and disabled, and best of all the source code is a little less eye-bleedy.

I really don't expect anyone to review this closely - it's *huge* chunk of boring search/replace change:

 94 files changed, 2929 insertions(+), 2652 deletions(-)

but I would like people to comment on/ack the approach I've taken here. If nobody objects/cares, I'll then do a 3.1.6 release early next week....

-Dave.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs