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

* [PATCH 0/8] xfsdump: Ouchie! My bleeding eyes!
@ 2015-10-16  1:44 Dave Chinner
  2015-10-16  1:44 ` [PATCH 1/8] cleanup: get rid of ASSERT Dave Chinner
                   ` (8 more replies)
  0 siblings, 9 replies; 17+ messages in thread
From: Dave Chinner @ 2015-10-16  1:44 UTC (permalink / raw)
  To: xfs

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
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 17+ messages in thread