On Thu, Jun 13, 2013 at 03:46:35PM -0400, Michael L. Semon wrote:
> This patch was made after applying the most recent 3.11-related
> patchset for xfsprogs. It was applied against the crc-dev branch,
> in order to get CRC-enabled xfsprogs to build without complaining
> about a lack of "umode_t". The systems used were both 32-bit
> slackware-current systems, against public kernel headers of kernel
> 3.8.x and 3.9.x vintage.
> This is an "idea" patch, a way of getting CRC-enabled xfsprogs to
> build on kernels later than 3.2 while staying within the conventions
> of my test systems. The idea may be bad, and the XFS crew might be
> solving it in a different way while moving header files and functions.
> Anyway, I don't know how the Debian and Red Hat crews solve header-
> related issues like these, so comments and flames are welcome. In
> particular, I'm open to a better name than "xfs_mode_t" that does
> not match the grep term "umode_t".
The usual way to do this is with autoconf magic.
The thing is, we want to keep the user and kernel code as close as
possible, so if the kernel code uses umode_t, then we need to use
that internally in the userspace code as well.
So what we need is an autoconf rule that detects is umode_t is
defined by the distro, and if it isn't define it ourselves.
See, for example, m4/package_types.m4 for how to detect if a
variable is already defined. Add a new rule to detect umode_t,
and use it to set a variable called have_umode_t. i.e.
then add a line like:
HAVE_UMODE_T = @have_umode_t@
to include/builddefs.in, as well as add this to the platform compile
flags like so:
PCFLAGS += -DHAVE_UMODE_T
then in include/platform_defs.h.in add something like:
typedef unsigned short umode_t;
And then you shouldn't have to modify any of the actual libxfs code
If you need help, just ping me ;)