Archive-Team
/
zfs
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 103 Wiki Activity
zfs/config/kernel-xattr-handler.m4

82 lines
2.1 KiB
Plaintext
Raw Normal View History

Linux 2.6.35 compat, const struct xattr_handler The const keyword was added to the 'struct xattr_handler' in the generic Linux super_block structure. To handle this we define an appropriate xattr_handler_t typedef which can be used. This was the preferred solution because it keeps the code clean and readable.
2011-02-11 00:16:52 +00:00
dnl #
dnl # 2.6.35 API change,
dnl # The 'struct xattr_handler' was constified in the generic
dnl # super_block structure.
dnl #
AC_DEFUN([ZFS_AC_KERNEL_CONST_XATTR_HANDLER],
[AC_MSG_CHECKING([whether super_block uses const struct xattr_hander])
ZFS_LINUX_TRY_COMPILE([
#include <linux/fs.h>
#include <linux/xattr.h>
const struct xattr_handler xattr_test_handler = {
.prefix = "test",
.get = NULL,
.set = NULL,
};
const struct xattr_handler *xattr_handlers[] = {
&xattr_test_handler,
};
],[
Fix gcc configure warnings Newer versions of gcc are getting smart enough to detect the sloppy syntax used for the autoconf tests. It is now generating warnings for unused/undeclared variables. Newer version of gcc even have the -Wunused-but-set-variable option set by default. This isn't a problem except when -Werror is set and they get promoted to an error. In this case the autoconf test will return an incorrect result which will result in a build failure latter on. To handle this I'm tightening up many of the autoconf tests to explicitly mark variables as unused to suppress the gcc warning. Remember, all of the autoconf code can never actually be run we just want to get a clean build error to detect which APIs are available. Never using a variable is absolutely fine for this. Closes #176
2011-04-19 17:02:21 +00:00
struct super_block sb __attribute__ ((unused));
Linux 2.6.35 compat, const struct xattr_handler The const keyword was added to the 'struct xattr_handler' in the generic Linux super_block structure. To handle this we define an appropriate xattr_handler_t typedef which can be used. This was the preferred solution because it keeps the code clean and readable.
2011-02-11 00:16:52 +00:00
sb.s_xattr = xattr_handlers;
],[
AC_MSG_RESULT([yes])
AC_DEFINE(HAVE_CONST_XATTR_HANDLER, 1,
[super_block uses const struct xattr_hander])
],[
AC_MSG_RESULT([no])
])
])
Linux 2.6.33 compat, get/set xattr callbacks The xattr handler prototypes were sanitized with the idea being that the same handlers could be used for multiple methods. The result of this was the inode type was changes to a dentry, and both the get() and set() hooks had a handler_flags argument added. The list() callback was similiarly effected but no autoconf check was added because we do not use the list() callback.
2011-02-11 18:33:01 +00:00
dnl #
dnl # 2.6.33 API change,
dnl # The xattr_hander->get() callback was changed to take a dentry
dnl # instead of an inode, and a handler_flags argument was added.
dnl #
AC_DEFUN([ZFS_AC_KERNEL_XATTR_HANDLER_GET], [
AC_MSG_CHECKING([whether xattr_handler->get() wants dentry])
ZFS_LINUX_TRY_COMPILE([
#include <linux/xattr.h>
],[
int (*get)(struct dentry *dentry, const char *name,
void *buffer, size_t size, int handler_flags) = NULL;
Fix gcc configure warnings Newer versions of gcc are getting smart enough to detect the sloppy syntax used for the autoconf tests. It is now generating warnings for unused/undeclared variables. Newer version of gcc even have the -Wunused-but-set-variable option set by default. This isn't a problem except when -Werror is set and they get promoted to an error. In this case the autoconf test will return an incorrect result which will result in a build failure latter on. To handle this I'm tightening up many of the autoconf tests to explicitly mark variables as unused to suppress the gcc warning. Remember, all of the autoconf code can never actually be run we just want to get a clean build error to detect which APIs are available. Never using a variable is absolutely fine for this. Closes #176
2011-04-19 17:02:21 +00:00
struct xattr_handler xops __attribute__ ((unused));
Linux 2.6.33 compat, get/set xattr callbacks The xattr handler prototypes were sanitized with the idea being that the same handlers could be used for multiple methods. The result of this was the inode type was changes to a dentry, and both the get() and set() hooks had a handler_flags argument added. The list() callback was similiarly effected but no autoconf check was added because we do not use the list() callback.
2011-02-11 18:33:01 +00:00
xops.get = get;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_DENTRY_XATTR_GET, 1,
[xattr_handler->get() wants dentry])
],[
AC_MSG_RESULT(no)
])
])
dnl #
dnl # 2.6.33 API change,
dnl # The xattr_hander->set() callback was changed to take a dentry
dnl # instead of an inode, and a handler_flags argument was added.
dnl #
AC_DEFUN([ZFS_AC_KERNEL_XATTR_HANDLER_SET], [
AC_MSG_CHECKING([whether xattr_handler->set() wants dentry])
ZFS_LINUX_TRY_COMPILE([
#include <linux/xattr.h>
],[
int (*set)(struct dentry *dentry, const char *name,
const void *buffer, size_t size, int flags,
int handler_flags) = NULL;
Fix gcc configure warnings Newer versions of gcc are getting smart enough to detect the sloppy syntax used for the autoconf tests. It is now generating warnings for unused/undeclared variables. Newer version of gcc even have the -Wunused-but-set-variable option set by default. This isn't a problem except when -Werror is set and they get promoted to an error. In this case the autoconf test will return an incorrect result which will result in a build failure latter on. To handle this I'm tightening up many of the autoconf tests to explicitly mark variables as unused to suppress the gcc warning. Remember, all of the autoconf code can never actually be run we just want to get a clean build error to detect which APIs are available. Never using a variable is absolutely fine for this. Closes #176
2011-04-19 17:02:21 +00:00
struct xattr_handler xops __attribute__ ((unused));
Linux 2.6.33 compat, get/set xattr callbacks The xattr handler prototypes were sanitized with the idea being that the same handlers could be used for multiple methods. The result of this was the inode type was changes to a dentry, and both the get() and set() hooks had a handler_flags argument added. The list() callback was similiarly effected but no autoconf check was added because we do not use the list() callback.
2011-02-11 18:33:01 +00:00
xops.set = set;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_DENTRY_XATTR_SET, 1,
[xattr_handler->set() wants dentry])
],[
AC_MSG_RESULT(no)
])
])