From: Dave Chinner <david@fromorbit.com>
To: "Michael L. Semon" <mlsemon35@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfsprogs: replace umode_t with xfs_mode_t
Date: Fri, 14 Jun 2013 12:37:58 +1000 [thread overview]
Message-ID: <20130614023758.GT29338@dastard> (raw)
In-Reply-To: <51BA219B.4070503@gmail.com>
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.
.....
], [
umode_t umode;
], have_umode_t=no
AC_MSG_RESULT(yes),
AC_MSG_RESULT(no))
AC_SUBST(have_umode_t)
])
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:
ifeq ($(HAVE_UMODE_T),yes)
PCFLAGS += -DHAVE_UMODE_T
endif
then in include/platform_defs.h.in add something like:
#ifndef HAVE_UMODE_T
typedef unsigned short umode_t;
#endif
And then you shouldn't have to modify any of the actual libxfs code
at all...
If you need help, just ping me ;)
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-06-14 2:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 19:46 [PATCH] xfsprogs: replace umode_t with xfs_mode_t Michael L. Semon
2013-06-14 2:37 ` Dave Chinner [this message]
2013-06-14 18:25 ` Michael L. Semon
2013-06-25 21:14 ` Ben Myers
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=20130614023758.GT29338@dastard \
--to=david@fromorbit.com \
--cc=mlsemon35@gmail.com \
--cc=xfs@oss.sgi.com \
/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