c/mirror_zfs
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_zfs.git synced 2024-11-17 18:11:00 +03:00
Code Issues Packages Projects Releases Wiki Activity
de2a22fcb3
mirror_zfs/config/spl-build.m4

2559 lines
66 KiB
Plaintext
Raw Normal View History

Public Release Prep Updated AUTHORS, COPYING, DISCLAIMER, and INSTALL files. Added standardized headers to all source file to clearly indicate the copyright, license, and to give credit where credit is due.
2010-05-18 02:18:00 +04:00
###############################################################################
# Copyright (C) 2007-2010 Lawrence Livermore National Security, LLC.
# Copyright (C) 2007 The Regents of the University of California.
# Written by Brian Behlendorf <behlendorf1@llnl.gov>.
###############################################################################
# SPL_AC_CONFIG_KERNEL: Default SPL kernel configuration.
###############################################################################
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
AC_DEFUN([SPL_AC_CONFIG_KERNEL], [
SPL_AC_KERNEL
if test "${LINUX_OBJ}" != "${LINUX}"; then
KERNELMAKE_PARAMS="$KERNELMAKE_PARAMS O=$LINUX_OBJ"
fi
AC_SUBST(KERNELMAKE_PARAMS)
Support custom build directories One of the neat tricks an autoconf style project is capable of is allow configurion/building in a directory other than the source directory. The major advantage to this is that you can build the project various different ways while making changes in a single source tree. For example, this project is designed to work on various different Linux distributions each of which work slightly differently. This means that changes need to verified on each of those supported distributions perferably before the change is committed to the public git repo. Using nfs and custom build directories makes this much easier. I now have a single source tree in nfs mounted on several different systems each running a supported distribution. When I make a change to the source base I suspect may break things I can concurrently build from the same source on all the systems each in their own subdirectory. wget -c http://github.com/downloads/behlendorf/spl/spl-x.y.z.tar.gz tar -xzf spl-x.y.z.tar.gz cd spl-x-y-z ------------------------- run concurrently ---------------------- <ubuntu system> <fedora system> <debian system> <rhel6 system> mkdir ubuntu mkdir fedora mkdir debian mkdir rhel6 cd ubuntu cd fedora cd debian cd rhel6 ../configure ../configure ../configure ../configure make make make make make check make check make check make check This is something the project has almost supported for a long time but finishing this support should save me lots of time.
2010-09-02 23:12:39 +04:00
KERNELCPPFLAGS="$KERNELCPPFLAGS -Wstrict-prototypes"
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
AC_SUBST(KERNELCPPFLAGS)
SPL_AC_DEBUG
Add --enable-debug-log configure option Until now the notion of an internal debug logging infrastructure was conflated with enabling ASSERT()s. This patch clarifies things by cleanly breaking the two subsystem apart. The result of this is the following behavior. --enable-debug - Enable/disable code wrapped in ASSERT()s. --disable-debug ASSERT()s are used to check invariants and are never required for correct operation. They are disabled by default because they may impact performance. --enable-debug-log - Enable/disable the debug log infrastructure. --disable-debug-log This infrastructure allows the spl code and its consumer to log messages to an in-kernel log. The granularity of the logging can be controlled by a debug mask. By default the mask disables most debug messages resulting in a negligible performance impact. Because of this the debug log is enabled by default. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-01-21 04:39:12 +04:00
SPL_AC_DEBUG_LOG
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
SPL_AC_DEBUG_KMEM
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
SPL_AC_DEBUG_KMEM_TRACKING
Make configure builtin-aware. This patch adds a new option to configure: --enable-linux-builtin. When this option is used, the following happens: - Compilation of kernel modules is disabled. - A failure to find UTS_RELEASE is followed by a suggestion to run "make prepare" on the kernel source tree. This patch also adds a new test which tries to compile an empty module as a basic toolchain sanity test. If it fails and the option was specified, the error is followed by a suggestion to run "make scripts" on the kernel source tree. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 18:34:43 +04:00
SPL_AC_TEST_MODULE
Use Linux atomic primitives by default. Previously Solaris style atomic primitives were implemented simply by wrapping the desired operation in a global spinlock. This was easy to implement at the time when I wasn't 100% sure I could safely layer the Solaris atomic primatives on the Linux counterparts. It however was likely not good for performance. After more investigation however it does appear the Solaris primitives can be layered on Linux's fairly safely. The Linux atomic_t type really just wraps a long so we can simply cast the Solaris unsigned value to either a atomic_t or atomic64_t. The only lingering problem for both implementations is that Solaris provides no atomic read function. This means reading a 64-bit value on a 32-bit arch can (and will) result in word breaking. I was very concerned about this initially, but upon further reflection it is a limitation of the Solaris API. So really we are just being bug-for-bug compatible here. With this change the default implementation is layered on top of Linux atomic types. However, because we're assuming a lot about the internal implementation of those types I've made it easy to fall-back to the generic approach. Simply build with --enable-atomic_spinlocks if issues are encountered with the new implementation.
2009-10-30 20:55:25 +03:00
SPL_AC_ATOMIC_SPINLOCK
Add autoconf checks for atomic64_cmpxchg + atomic64_xchg These functions didn't exist for all archs prior to 2.6.24. This patch addes an autoconf test to detect this and add them when needed. The autoconf check is needed instead of just an #ifndef because in the most modern kernels atomic64_{cmp}xchg are implemented as in inline function and not a #define.
2009-10-30 23:53:17 +03:00
SPL_AC_TYPE_ATOMIC64_CMPXCHG
SPL_AC_TYPE_ATOMIC64_XCHG
Atomic64 compatibility for 32-bit systems without kernel support. This patch is another step towards updating the code to handle the 32-bit kernels which I have not been regularly testing. This changes do not really impact the common case I'm expected which is the latest kernel running on an x86_64 arch. Until the linux-2.6.31 kernel the x86 arch did not have support for 64-bit atomic operations. Additionally, the new atomic_compat.h support for this case was wrong because it embedded a spinlock in the atomic variable which must always and only be 64-bits total. To handle these 32-bit issues we now simply fall back to the --enable-atomic-spinlock implementation if the kernel does not provide the 64-bit atomic funcs. The second issue this patch addresses is the DEBUG_KMEM assumption that there will always be atomic64 funcs available. On 32-bit archs this may not be true, and actually that's just fine. In that case the kernel will will never be able to allocate more the 32-bits worth anyway. So just check if atomic64 funcs are available, if they are not it means this is a 32-bit machine and we can safely use atomic_t's instead.
2009-12-05 02:54:12 +03:00
SPL_AC_TYPE_UINTPTR_T
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
SPL_AC_2ARGS_REGISTER_SYSCTL
Linux 3.12 compat: New shrinker API torvalds/linux@24f7c6 introduced a new shrinker API while torvalds/linux@a0b021 dropped support for the old shrinker API. This patch adds support for the new shrinker API by wrapping the old one with the new one. This change also reorganizes the autotools checks on the shrinker API such that the configure script will fail early if an unknown API is encountered in the future. Support for the set_shrinker() API which was used by Linux 2.6.22 and older has been dropped. As a general rule compatibility is only maintained back to Linux 2.6.26. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#1732 Closes zfsonlinux/zfs#1822 Closes #293 Closes #307
2013-11-05 20:35:54 +04:00
SPL_AC_SHRINKER_CALLBACK
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
SPL_AC_TASK_CURR
SPL_AC_CTL_UNNUMBERED
Linux-2.6.33 compat, .ctl_name removed from struct ctl_table As of linux-2.6.33 the ctl_name member of the ctl_table struct has been entirely removed. The upstream code has been updated to depend entirely on the the procname member. To handle this all references to ctl_name are wrapped in a CTL_NAME macro which simply expands to nothing for newer kernels. Older kernels are supported by having it expand to .ctl_name = X just as before.
2010-06-30 21:36:20 +04:00
SPL_AC_CTL_NAME
Linux 3.10 compat: struct vmalloc_info moved Linux kernel commmit torvalds/linux@db3808c1 moved the vmalloc_info structure from a private to a public header. Now that it's available for kernel modules use it. Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #257
2013-05-14 04:31:53 +04:00
SPL_AC_VMALLOC_INFO
Linux 3.10 compat: replace PDE()->data with PDE_DATA() Linux kernel commit torvalds/linux@d9dda78b renamed PDE() to PDE_DATA(). To handle this detect the prefered interface and define a PDE_DATA() wrapper for consistency. Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com> Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #257
2013-05-14 04:39:26 +04:00
SPL_AC_PDE_DATA
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
SPL_AC_FLS64
SPL_AC_DEVICE_CREATE
SPL_AC_5ARGS_DEVICE_CREATE
SPL_AC_CLASS_DEVICE_CREATE
SPL_AC_SET_NORMALIZED_TIMESPEC_EXPORT
SPL_AC_SET_NORMALIZED_TIMESPEC_INLINE
SPL_AC_TIMESPEC_SUB
SPL_AC_INIT_UTSNAME
SPL_AC_UACCESS_HEADER
SPL_AC_KMALLOC_NODE
SPL_AC_MONOTONIC_CLOCK
SPL_AC_INODE_I_MUTEX
Reimplement mutexs for Linux lock profiling/analysis For a generic explanation of why mutexs needed to be reimplemented to work with the kernel lock profiling see commits: e811949a57044d60d12953c5c3b808a79a7d36ef and d28db80fd0fd4fd63aec09037c44408e51a222d6 The specific changes made to the mutex implemetation are as follows. The Linux mutex structure is now directly embedded in the kmutex_t. This allows a kmutex_t to be directly case to a mutex struct and passed directly to the Linux primative. Just like with the rwlocks it is critical that these functions be implemented as '#defines to ensure the location information is preserved. The preprocessor can then do a direct replacement of the Solaris primative with the linux primative. Just as with the rwlocks we need to track the lock owner. Here things get a little more interesting because depending on your kernel version, and how you've built your kernel Linux may already do this for you. If your running a 2.6.29 or newer kernel on a SMP system the lock owner will be tracked. This was added to Linux to support adaptive mutexs, more on that shortly. Alternately, your kernel might track the lock owner if you've set CONFIG_DEBUG_MUTEXES in the kernel build. If neither of the above things is true for your kernel the kmutex_t type will include and track the lock owner to ensure correct behavior. This is all handled by a new autoconf check called SPL_AC_MUTEX_OWNER. Concerning adaptive mutexs these are a very recent development and they did not make it in to either the latest FC11 of SLES11 kernels. Ideally, I'd love to see this kernel change appear in one of these distros because it does help performance. From Linux kernel commit: 0d66bf6d3514b35eb6897629059443132992dbd7 "Testing with Ingo's test-mutex application... gave a 345% boost for VFS scalability on my testbox" However, if you don't want to backport this change yourself you can still simply export the task_curr() symbol. The kmutex_t implementation will use this symbol when it's available to provide it's own adaptive mutexs. Finally, DEBUG_MUTEX support was removed including the proc handlers. This was done because now that we are cleanly integrated with the kernel profiling all this information and much much more is available in debug kernel builds. This code was now redundant. Update mutexs validated on: - SLES10 (ppc64) - SLES11 (x86_64) - CHAOS4.2 (x86_64) - RHEL5.3 (x86_64) - RHEL6 (x86_64) - FC11 (x86_64)
2009-09-26 01:47:01 +04:00
SPL_AC_MUTEX_OWNER
Linux 2.6.39 compat, mutex owner Prior to Linux 2.6.39 when CONFIG_DEBUG_MUTEXES was defined the kernel stored a thread_info pointer as the mutex owner. From this you could get the pointer of the current task_struct to compare with get_current(). As of Linux 2.6.39 this behavior has changed and now the mutex stores a pointer to the task_struct. This commit detects the type of pointer stored in the mutex and adjusts the mutex_owner() and mutex_owned() functions to perform the correct comparision.
2011-06-24 22:57:14 +04:00
SPL_AC_MUTEX_OWNER_TASK_STRUCT
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
SPL_AC_MUTEX_LOCK_NESTED
SPL_AC_3ARGS_ON_EACH_CPU
SPL_AC_KALLSYMS_LOOKUP_NAME
SPL_AC_GET_VMALLOC_INFO
SPL_AC_PGDAT_HELPERS
SPL_AC_FIRST_ONLINE_PGDAT
SPL_AC_NEXT_ONLINE_PGDAT
SPL_AC_NEXT_ZONE
SPL_AC_PGDAT_LIST
SPL_AC_GLOBAL_PAGE_STATE
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
SPL_AC_ZONE_STAT_ITEM_FREE
SPL_AC_ZONE_STAT_ITEM_INACTIVE
SPL_AC_ZONE_STAT_ITEM_ACTIVE
SPL_AC_GET_ZONE_COUNTS
Add configure check for user_path_dir() I didn't notice at the time but user_path_dir() was not introduced at the same time as set_fs_pwd() change. I had lumped the two together but in fact user_path_dir() was introduced in 2.6.27 and set_fs_pwd() taking 2 args was introduced in 2.6.25. This means builds against 2.6.25-2.6.26 kernels were broken. To fix this I've added a check for user_path_dir() and no longer assume that if set_fs_pwd() takes 2 args then user_path_dir() is also available.
2010-07-02 00:37:43 +04:00
SPL_AC_USER_PATH_DIR
Set cwd to '/' for the process executing insmod. Ricardo has pointed out that under Solaris the cwd is set to '/' during module load, while under Linux it is set to the callers cwd. To handle this cleanly I've reworked the module *_init()/_exit() macros so they call a *_setup()/_cleanup() function when any SPL dependent module is loaded or unloaded. This gives us a chance to perform any needed modification of the process, in this case changing the cwd. It also handily provides a way to avoid creating wrapper init()/exit() functions because the Solaris and Linux prototypes differ slightly. All dependent modules should now call the spl helper macros spl_module_{init,exit}() instead of the native linux versions. Unfortunately, it appears that under Linux there has been no consistent API in the kernel to set the cwd in a module. Because of this I have had to add more autoconf magic than I'd like. However, what I have done is correct and has been tested on RHEL5, SLES11, FC11, and CHAOS kernels. In addition, I have change the rootdir type from a 'void *' to the correct 'vnode_t *' type. And I've set rootdir to a non-NULL value.
2009-10-02 03:06:15 +04:00
SPL_AC_SET_FS_PWD
Linux 3.9 compat: set_fs_root takes const struct path * torvalds/linux@dcf787f39162ce32ca325b3e784aba2d2444619a enforces const-correctness in passing struct path *. Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-03-04 09:24:04 +04:00
SPL_AC_SET_FS_PWD_WITH_CONST
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
SPL_AC_2ARGS_VFS_UNLINK
SPL_AC_4ARGS_VFS_RENAME
Linux 3.1 compat, vfs_fsync() Preferentially use the vfs_fsync() function. This function was initially introduced in 2.6.29 and took three arguments. As of 2.6.35 the dentry argument was dropped from the function. For older kernels fall back to using file_fsync() which also took three arguments including the dentry. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #52
2011-11-10 00:45:35 +04:00
SPL_AC_VFS_FSYNC
SPL_AC_2ARGS_VFS_FSYNC
Add interface for file hole punching. This adds an interface to "punch holes" (deallocate space) in VFS files. The interface is identical to the Solaris VOP_SPACE interface. This interface is necessary for TRIM support on file vdevs. This is implemented using Linux fallocate(FALLOC_FL_PUNCH_HOLE), which was introduced in 2.6.38. For a brief time before 2.6.38 this was done using the truncate_range inode operation, which was quickly deprecated. This patch only supports FALLOC_FL_PUNCH_HOLE. This adds support for the truncate_range() inode operation to VOP_SPACE() for file hole punching. This API is deprecated and removed in 3.5, so it's only useful for old kernels. On tmpfs, the truncate_range() inode operation translates to shmem_truncate_range(). Unfortunately, this function expects the end offset to be inclusive and aligned to the end of a page. If it is not, the kernel will stop with a BUG_ON(). This patch fixes the issue by adapting to the constraints set forth by shmem_truncate_range(). Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #168
2012-09-03 16:56:26 +04:00
SPL_AC_INODE_TRUNCATE_RANGE
Linux 2.6.36 compat, fs_struct->lock type change In the linux-2.6.36 kernel the fs_struct lock was changed from a rwlock_t to a spinlock_t. If the kernel would export the set_fs_pwd() symbol by default this would not have caused us any issues, but they don't. So we're forced to add a new autoconf check which sets the HAVE_FS_STRUCT_SPINLOCK define when a spinlock_t is used. We can then correctly use either spin_lock or write_lock in our custom set_fs_pwd() implementation.
2010-11-09 22:15:32 +03:00
SPL_AC_FS_STRUCT_SPINLOCK
Add basic credential support and splat tests. The previous credential implementation simply provided the needed types and a couple of dummy functions needed. This update correctly ties the basic Solaris credential API in to one of two Linux kernel APIs. Prior to 2.6.29 the linux kernel embeded all credentials in the task structure. For these kernels, we pass around the entire task struct as if it were the credential, then we use the helper functions to extract the credential related bits. As of 2.6.29 a new credential type was added which we can and do fairly cleanly layer on top of. Once again the helper functions nicely hide the implementation details from all callers. Three tests were added to the splat test framework to verify basic correctness. They should be extended as needed when need credential functions are added.
2009-07-28 04:18:59 +04:00
SPL_AC_CRED_STRUCT
Linux 3.8 compat: Use kuid_t/kgid_t when required When CONFIG_UIDGID_STRICT_TYPE_CHECKS is enabled uid_t/git_t are replaced by kuid_t/kgid_t, which are structures instead of integral types. This causes any code that uses an integral type to fail to build. The User Namespace functionality introduced in Linux 3.8 requires CONFIG_UIDGID_STRICT_TYPE_CHECKS, so we could not build against any kernel that supported it. We resolve this by converting between the new kuid_t/kgid_t structures and the original uid_t/gid_t types. Original-patch-by: DHE Rewrite-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #260
2013-07-14 00:34:56 +04:00
SPL_AC_KUIDGID_T
Add basic credential support and splat tests. The previous credential implementation simply provided the needed types and a couple of dummy functions needed. This update correctly ties the basic Solaris credential API in to one of two Linux kernel APIs. Prior to 2.6.29 the linux kernel embeded all credentials in the task structure. For these kernels, we pass around the entire task struct as if it were the credential, then we use the helper functions to extract the credential related bits. As of 2.6.29 a new credential type was added which we can and do fairly cleanly layer on top of. Once again the helper functions nicely hide the implementation details from all callers. Three tests were added to the splat test framework to verify basic correctness. They should be extended as needed when need credential functions are added.
2009-07-28 04:18:59 +04:00
SPL_AC_GROUPS_SEARCH
Reimplement rwlocks for Linux lock profiling/analysis. It turns out that the previous rwlock implementation worked well but did not integrate properly with the upstream kernel lock profiling/ analysis tools. This is a major problem since it would be awfully nice to be able to use the automatic lock checker and profiler. The problem is that the upstream lock tools use the pre-processor to create a lock class for each uniquely named locked. Since the rwsem was embedded in a wrapper structure the name was always the same. The effect was that we only ended up with one lock class for the entire SPL which caused the lock dependency checker to flag nearly everything as a possible deadlock. The solution was to directly map a krwlock to a Linux rwsem using a typedef there by eliminating the wrapper structure. This was not done initially because the rwsem implementation is specific to the arch. To fully implement the Solaris krwlock API using only the provided rwsem API is not possible. It can only be done by directly accessing some of the internal data member of the rwsem structure. For example, the Linux API provides a different function for dropping a reader vs writer lock. Whereas the Solaris API uses the same function and the caller does not pass in what type of lock it is. This means to properly drop the lock we need to determine if the lock is currently a reader or writer lock. Then we need to call the proper Linux API function. Unfortunately, there is no provided API for this so we must extracted this information directly from arch specific lock implementation. This is all do able, and what I did, but it does complicate things considerably. The good news is that in addition to the profiling benefits of this change. We may see performance improvements due to slightly reduced overhead when creating rwlocks and manipulating them. The only function I was forced to sacrafice was rw_owner() because this information is simply not stored anywhere in the rwsem. Luckily this appears not to be a commonly used function on Solaris, and it is my understanding it is mainly used for debugging anyway. In addition to the core rwlock changes, extensive updates were made to the rwlock regression tests. Each class of test was extended to provide more API coverage and to be more rigerous in checking for misbehavior. This is a pretty significant change and with that in mind I have been careful to validate it on several platforms before committing. The full SPLAT regression test suite was run numberous times on all of the following platforms. This includes various kernels ranging from 2.6.16 to 2.6.29. - SLES10 (ppc64) - SLES11 (x86_64) - CHAOS4.2 (x86_64) - RHEL5.3 (x86_64) - RHEL6 (x86_64) - FC11 (x86_64)
2009-09-19 03:09:47 +04:00
SPL_AC_PUT_TASK_STRUCT
Linux 2.6.32 compat, proc_handler() API change As of linux-2.6.32 the 'struct file *filp' argument was dropped from the proc_handle() prototype. It was apparently unused _almost_ everywhere in the kernel and this was simply cleanup. I've added a new SPL_AC_5ARGS_PROC_HANDLER autoconf check for this and the proper compat macros to correctly define the prototypes and some helper functions. It's not pretty but API compat changes rarely are.
2010-03-04 23:14:56 +03:00
SPL_AC_5ARGS_PROC_HANDLER
Add kmem_asprintf(), strfree(), strdup(), and minor cleanup. This patch adds three missing Solaris functions: kmem_asprintf(), strfree(), and strdup(). They are all implemented as a thin layer which just calls their Linux counterparts. As part of this an autoconf check for kvasprintf was added because it does not appear in older kernels. If the kernel does not provide it then spl-generic implements it. Additionally the dead DEBUG_KMEM_UNIMPLEMENTED code was removed to clean things up and make the kmem.h a little more readable.
2010-06-12 01:48:18 +04:00
SPL_AC_KVASPRINTF
Correctly handle rwsem_is_locked() behavior A race condition in rwsem_is_locked() was fixed in Linux 2.6.33 and the fix was backported to RHEL5 as of kernel 2.6.18-190.el5. Details can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=526092 The race condition was fixed in the kernel by acquiring the semaphore's wait_lock inside rwsem_is_locked(). The SPL worked around the race condition by acquiring the wait_lock before calling that function, but with the fix in place it must not do that. This commit implements an autoconf test to detect whether the fixed version of rwsem_is_locked() is present. The previous version of rwsem_is_locked() was an inline static function while the new version is exported as a symbol which we can check for in module.symvers. Depending on the result we correctly implement the needed compatibility macros for proper spinlock handling. Finally, we do the right thing with spin locks in RW_*_HELD() by using the new compatibility macros. We only only acquire the semaphore's wait_lock if it is calling a rwsem_is_locked() that does not itself try to acquire the lock. Some new overhead and a small harmless race is introduced by this change. This is because RW_READ_HELD() and RW_WRITE_HELD() now acquire and release the wait_lock twice: once for the call to rwsem_is_locked() and once for the call to rw_owner(). This can't be avoided if calling a rwsem_is_locked() that takes the wait_lock, as it will in more recent kernels. The other case which only occurs in legacy kernels could be optimized by taking the lock only once, as was done prior to this commit. However, I decided that the performance gain probably wasn't significant enough to justify the messy special cases required. The function spl_rw_get_owner() was only used to enable the afore-mentioned optimization. Since it is no longer used, I removed it. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2010-08-10 22:01:46 +04:00
SPL_AC_EXPORTED_RWSEM_IS_LOCKED
RHEL 6.4 compat, fallocate() In the upstream kernel the FALLOC_FL_PUNCH_HOLE #define was introduced after the fallocate() function was moved from the inode_operations to the file_operations structure. Therefore, the SPL code assumed that if FALLOC_FL_PUNCH_HOLE was defined it was safe to use f_ops->fallocate(). Unfortunately, the RHEL6.4 kernel has only backported the FALLOC_FL_PUNCH_HOLE #define and not the fallocate() change. To address this compatibility issue the spl_filp_fallocate() helper function was added to properly detect which interface is available. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-01-08 21:42:49 +04:00
SPL_AC_KERNEL_FALLOCATE
Add dnlc_reduce_cache() support Provide the dnlc_reduce_cache() function which attempts to prune cached entries from the dcache and icache. After the entries are pruned any slabs which they may have been using are reaped. Note the API takes a reclaim percentage but we don't have easy access to the total number of cache entries to calculate the reclaim count. However, in practice this doesn't need to be exactly correct. We simply need to reclaim some useful fraction (but not all) of the cache. The caller can determine if more needs to be done.
2011-03-31 04:44:35 +04:00
SPL_AC_SHRINK_DCACHE_MEMORY
SPL_AC_SHRINK_ICACHE_MEMORY
Cleanup vn_rename() and vn_remove() zfsonlinux/spl#bcb15891ab394e11615eee08bba1fd85ac32e158 implemented Linux 3.6+ support by adding duplicate vn_rename and vn_remove functions. The new ones were cleaner, but the duplicate functions made the codebase less maintainable. This adds some compatibility shims that allow us to retire the older vn_rename and vn_remove in favor of the new ones on old kernels. The result is a net 143 line reduction in lines of code and a cleaner codebase. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #370
2014-06-29 09:00:02 +04:00
SPL_AC_KERN_PATH
Check for KALLSYMS Check at ./configure time that the kernel was built with kallsyms support. If the kernel doesn't have CONFIG_KALLSYMS defined the modules will still compile cleanly but will not be loadable. So we really want to catch this early during ./configure. Note that we do not require CONFIG_KALLSYMS_ALL but it may be safely defined. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #6
2013-01-30 04:13:07 +04:00
SPL_AC_CONFIG_KALLSYMS
Check for ZLIB_INFLATE and ZLIB_DEFLATE Check at ./configure time that the kernel was built with zlib support enabled. This support may either be configured as a module or builtin to the kernel. But if it's missing the build will fail so it's best to catch this early. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#582
2013-01-10 03:26:46 +04:00
SPL_AC_CONFIG_ZLIB_INFLATE
SPL_AC_CONFIG_ZLIB_DEFLATE
Linux 2.6.39 compat, zlib_deflate_workspacesize() The function zlib_deflate_workspacesize() now take 2 arguments. This was done to avoid always having to allocate the maximum size workspace (268K). The caller can now specific the windowBits and memLevel compression parameters to get a smaller workspace. For our purposes we introduce a spl_zlib_deflate_workspacesize() wrapper which accepts both arguments. When the two argument version of zlib_deflate_workspacesize() is available the arguments are passed through. When it's not we assume the worst case and a maximally sized workspace is used.
2011-04-21 01:22:35 +04:00
SPL_AC_2ARGS_ZLIB_DEFLATE_WORKSPACESIZE
Linux 3.0: Shrinker compatibility Update the the wrapper macros for the memory shrinker to handle this 4th API change. The callback function now takes a shrink_control structure. This is certainly a step in the right direction but it's annoying to have to accomidate yet another version of the API.
2011-06-17 02:39:08 +04:00
SPL_AC_SHRINK_CONTROL_STRUCT
Linux 3.2 compat: rw_semaphore.wait_lock is raw The wait_lock member of the rw_semaphore struct became a raw_spinlock_t in Linux 3.2 at torvalds/linux@ddb6c9b58a19edcfac93ac670b066c836ff729f1. Wrap spin_lock_* function calls in a new spl_rwsem_* interface to ensure type safety if raw_spinlock_t becomes architecture specific, and to satisfy these compiler warnings: warning: passing argument 1 of ‘spinlock_check’ from incompatible pointer type [enabled by default] note: expected ‘struct spinlock_t *’ but argument is of type ‘struct raw_spinlock_t *’ Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes: #76 Closes: zfsonlinux/zfs#463
2012-01-11 21:44:34 +04:00
SPL_AC_RWSEM_SPINLOCK_IS_RAW
Linux 3.9 compat: Include linux/sched/rt.h Linux 3.9 reorganized sched.h, splitting it into numerous files. torvalds/linux@8bd75c77b7c6a3954140dd2e20346aef3efe4a35 moved MAX_PRIO and MAX_RT_PRIO to linux/sched/rt.h. Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-03-04 08:42:32 +04:00
SPL_AC_SCHED_RT_HEADER
Linux 3.9 compat: vfs_getattr takes two arguments The function prototype of vfs_getattr previoulsy took struct vfsmount * and struct dentry * as arguments. These would always be defined together in a struct path *. torvalds/linux@3dadecce20603aa380023c65e6f55f108fd5e952 modified vfs_getattr to take struct path * is taken as an argument instead. Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-03-04 09:02:43 +04:00
SPL_AC_2ARGS_VFS_GETATTR
Emulate illumos interface cv_timedwait_hires() Needed for Illumos #3582. This interface is supposed to support a variable-resolution timeout with nanosecond granularity. This implementation rounds up to microsecond resolution, as nanosecond- precision timing is rarely needed for real-world performance tuning and may incur unnecessary busy-waiting. usleep_range() is used if available, otherwise udelay() or msleep() are used depending on the length of the delay interval. Add flags from sys/callo.h as these are used to control the behavior of cv_timedwait_hires(). Specifically, CALLOUT_FLAG_ABSOLUTE Normally, the expiration passed to the timeout API functions is an expiration interval. If this flag is specified, then it is interpreted as the expiration time itself. CALLOUT_FLAG_ROUNDUP Roundup the expiration time to the next resolution boundary. If this flag is not specified, the expiration time is rounded down. References: https://www.illumos.org/issues/3582 illumos/illumos-gate@0689f76 Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #304
2013-11-02 00:37:58 +04:00
SPL_AC_USLEEP_RANGE
Add KMC_SLAB cache type For small objects the Linux slab allocator has several advantages over its counterpart in the SPL. These include: 1) It is more memory-efficient and packs objects more tightly. 2) It is continually tuned to maximize performance. Therefore it makes sense to layer the SPLs slab allocator on top of the Linux slab allocator. This allows us to leverage the advantages above while preserving the Illumos semantics we depend on. However, there are some things we need to be careful of: 1) The Linux slab allocator was never designed to work well with large objects. Because the SPL slab must still handle this use case a cut off limit was added to transition from Linux slab backed objects to kmem or vmem backed slabs. spl_kmem_cache_slab_limit - Objects less than or equal to this size in bytes will be backed by the Linux slab. By default this value is zero which disables the Linux slab functionality. Reasonable values for this cut off limit are in the range of 4096-16386 bytes. spl_kmem_cache_kmem_limit - Objects less than or equal to this size in bytes will be backed by a kmem slab. Objects over this size will be vmem backed instead. This value defaults to 1/8 a page, or 512 bytes on an x86_64 architecture. 2) Be aware that using the Linux slab may inadvertently introduce new deadlocks. Care has been taken previously to ensure that all allocations which occur in the write path use GFP_NOIO. However, there may be internal allocations performed in the Linux slab which do not honor these flags. If this is the case a deadlock may occur. The path forward is definitely to start relying on the Linux slab. But for that to happen we need to start building confidence that there aren't any unexpected surprises lurking for us. And ideally need to move completely away from using the SPLs slab for large memory allocations. This patch is a first step. NOTES: 1) The KMC_NOMAGAZINE flag was leveraged to support the Linux slab backed caches but it is not supported for kmem/vmem backed caches. 2) Regardless of the spl_kmem_cache_*_limit settings a cache may be explicitly set to a given type by passed the KMC_KMEM, KMC_VMEM, or KMC_SLAB flags during cache creation. 3) The constructors, destructors, and reclaim callbacks are all functional and will be called regardless of the cache type. 4) KMC_SLAB caches will not appear in /proc/spl/kmem/slab due to the issues involved in presenting correct object accounting. Instead they will appear in /proc/slabinfo under the same names. 5) Several kmem SPLAT tests needed to be fixed because they relied incorrectly on internal kmem slab accounting. With the updated test cases all the SPLAT tests pass as expected. 6) An autoconf test was added to ensure that the __GFP_COMP flag was correctly added to the default flags used when allocating a slab. This is required to ensure all pages in higher order slabs are properly refcounted, see ae16ed9. 7) When using the SLUB allocator there is no need to attempt to set the __GFP_COMP flag. This has been the default behavior for the SLUB since Linux 2.6.25. 8) When using the SLUB it may be desirable to set the slub_nomerge kernel parameter to prevent caches from being merged. Original-patch-by: DHE <git@dehacked.net> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Prakash Surya <surya1@llnl.gov> Signed-off-by: Tim Chase <tim@chase2k.com> Signed-off-by: DHE <git@dehacked.net> Signed-off-by: Chunwei Chen <tuxoko@gmail.com> Closes #356
2013-12-09 02:01:45 +04:00
SPL_AC_KMEM_CACHE_ALLOCFLAGS
Linux 3.17 compat: remove wait_on_bit action function Linux kernel 3.17 removes the action function argument from wait_on_bit(). Add autoconf test and compatibility macro to support the new interface. The former "wait_on_bit" interface required an 'action' function to be provided which does the actual waiting. There were over 20 such functions in the kernel, many of them identical, though most cases can be satisfied by one of just two functions: one which uses io_schedule() and one which just uses schedule(). This API change was made to consolidate all of those redundant wait functions. References: torvalds/linux@7431620 Signed-off-by: Ned Bass <bass6@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #378
2014-08-09 04:41:22 +04:00
SPL_AC_WAIT_ON_BIT
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
])
AC_DEFUN([SPL_AC_MODULE_SYMVERS], [
Cleanly handle --with-linux=NONE option when used to generate source rpms. These should not be fatal because we actually don't need them until we build the source rpm. When doing mock builds this is important because these dependent rpms will only be installed if they are specificed in the source rpms spec file.
2009-07-02 21:47:28 +04:00
modpost=$LINUX/scripts/Makefile.modpost
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
AC_MSG_CHECKING([kernel file name for module symbols])
Make configure builtin-aware. This patch adds a new option to configure: --enable-linux-builtin. When this option is used, the following happens: - Compilation of kernel modules is disabled. - A failure to find UTS_RELEASE is followed by a suggestion to run "make prepare" on the kernel source tree. This patch also adds a new test which tries to compile an empty module as a basic toolchain sanity test. If it fails and the option was specified, the error is followed by a suggestion to run "make scripts" on the kernel source tree. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 18:34:43 +04:00
if test "x$enable_linux_builtin" != xyes -a -f "$modpost"; then
Cleanly handle --with-linux=NONE option when used to generate source rpms. These should not be fatal because we actually don't need them until we build the source rpm. When doing mock builds this is important because these dependent rpms will only be installed if they are specificed in the source rpms spec file.
2009-07-02 21:47:28 +04:00
if grep -q Modules.symvers $modpost; then
LINUX_SYMBOLS=Modules.symvers
else
LINUX_SYMBOLS=Module.symvers
fi
Make Missing Modules.symvers Fatal Detect early on in configure if the Modules.symvers file is missing. Without this file there will be build failures later and it's best to catch this early and provide a useful error. In this case the most likely problem is the kernel-devel packages are not installed. It may also be possible that they are using an unbuilt custom kernel in which case they must build the kernel first.
2011-03-07 23:59:30 +03:00
if ! test -f "$LINUX_OBJ/$LINUX_SYMBOLS"; then
AC_MSG_ERROR([
*** Please make sure the kernel devel package for your distribution
build: resolve orthographic and other grammatical errors Signed-off-by: Jan Engelhardt <jengelh@inai.de> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-03-30 06:27:50 +04:00
*** is installed. If you are building with a custom kernel, make sure the
Make Missing Modules.symvers Fatal Detect early on in configure if the Modules.symvers file is missing. Without this file there will be build failures later and it's best to catch this early and provide a useful error. In this case the most likely problem is the kernel-devel packages are not installed. It may also be possible that they are using an unbuilt custom kernel in which case they must build the kernel first.
2011-03-07 23:59:30 +03:00
*** kernel is configured, built, and the '--with-linux=PATH' configure
*** option refers to the location of the kernel source.])
fi
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
else
Cleanly handle --with-linux=NONE option when used to generate source rpms. These should not be fatal because we actually don't need them until we build the source rpm. When doing mock builds this is important because these dependent rpms will only be installed if they are specificed in the source rpms spec file.
2009-07-02 21:47:28 +04:00
LINUX_SYMBOLS=NONE
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
fi
AC_MSG_RESULT($LINUX_SYMBOLS)
AC_SUBST(LINUX_SYMBOLS)
])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
AC_DEFUN([SPL_AC_KERNEL], [
AC_ARG_WITH([linux],
AS_HELP_STRING([--with-linux=PATH],
[Path to kernel source]),
Packaging improvements for RHEL and SLES - Properly honor --prefix in build system and rpm spec file. - Add '--define require_kdir' to spec file to support building rpms against kernel sources installed in non-default locations. - Add '--define require_kobj' to spec file to support building rpms against kernel object installed in non-default locations. - Stop suppressing errors in autogen.sh script. - Improved logic to detect missing kernel objects when they are not located with the source. This is the common case for SLES as well as in-tree chaos kernel builds and is done to simply support for multiple arches. - Moved spl-devel build products to /usr/src/spl-<version>, a spl symlink is created to reference the last installed version.
2009-06-16 21:44:59 +04:00
[kernelsrc="$withval"])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
AC_ARG_WITH([linux-obj],
AS_HELP_STRING([--with-linux-obj=PATH],
[Path to kernel build objects]),
[kernelbuild="$withval"])
AC_MSG_CHECKING([kernel source directory])
if test -z "$kernelsrc"; then
Prefer /lib/modules/$(uname -r)/ links Preferentially use the /lib/modules/$(uname -r)/source and /lib/modules/$(uname -r)/build links. Only if neither of these links exist fallback to alternate methods for deducing which kernel to build with. This resolves the need to manually specify --with-linux= and --with-linux-obj= on Debian systems.
2011-02-11 01:40:57 +03:00
if test -e "/lib/modules/$(uname -r)/source"; then
headersdir="/lib/modules/$(uname -r)/source"
sourcelink=$(readlink -f "$headersdir")
elif test -e "/lib/modules/$(uname -r)/build"; then
headersdir="/lib/modules/$(uname -r)/build"
When no kernel source has been pointed to, first attempt to use /lib/modules/$(uname -r)/source. This will likely fail when building under a mock (http://fedoraproject.org/wiki/Projects/Mock) chroot environment since `uname -r` will report the running kernel which likely is not the kernel in your chroot. To cleanly handle this we fallback to using the first kernel in your chroot. The kernel-devel package which contains all the kernel headers and a few build products such as Module.symver{s} is all the is required. Full source is not needed.
2010-03-09 01:19:30 +03:00
sourcelink=$(readlink -f "$headersdir")
else
sourcelink=$(ls -1d /usr/src/kernels/* \
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
/usr/src/linux-* \
When no kernel source has been pointed to, first attempt to use /lib/modules/$(uname -r)/source. This will likely fail when building under a mock (http://fedoraproject.org/wiki/Projects/Mock) chroot environment since `uname -r` will report the running kernel which likely is not the kernel in your chroot. To cleanly handle this we fallback to using the first kernel in your chroot. The kernel-devel package which contains all the kernel headers and a few build products such as Module.symver{s} is all the is required. Full source is not needed.
2010-03-09 01:19:30 +03:00
2>/dev/null | grep -v obj | tail -1)
fi
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
Check sourcelink is set before passing to readlink When no source was found in any of the expected paths treat this as fatal and provide the user with a hint as to what they should do.
2010-07-02 00:25:34 +04:00
if test -n "$sourcelink" && test -e ${sourcelink}; then
Build System Default Kernel Update the method used for determining which kernel to build against when not specified. Previous 'uname -r' was used but this makes the assumption that the running kernel is the one you want to use, this is often not the case. It is better to examine the usual kernel-devel install locations and select one of the installed kernels.
2009-03-10 02:50:37 +03:00
kernelsrc=`readlink -f ${sourcelink}`
else
Verify --with-linux source directory exists Previously this check was only performed when ./configure was attempting to autodetect your kernel source directory. But we should also handle the case where --with-linux was provided and is obviously wrong. This way we catch the error before invoking make and compiling the source with an incorrect autoconf results. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #162
2012-11-30 07:26:19 +04:00
kernelsrc="[Not found]"
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
fi
Build system and packaging (RPM support) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild spl-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all spl modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the spl. spl-x.y.z-1_<kernel version>.x86_64.rpm spl-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-05 20:08:07 +03:00
else
if test "$kernelsrc" = "NONE"; then
kernsrcver=NONE
fi
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
fi
AC_MSG_RESULT([$kernelsrc])
Verify --with-linux source directory exists Previously this check was only performed when ./configure was attempting to autodetect your kernel source directory. But we should also handle the case where --with-linux was provided and is obviously wrong. This way we catch the error before invoking make and compiling the source with an incorrect autoconf results. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #162
2012-11-30 07:26:19 +04:00
if test ! -d "$kernelsrc"; then
AC_MSG_ERROR([
*** Please make sure the kernel devel package for your distribution
build: resolve orthographic and other grammatical errors Signed-off-by: Jan Engelhardt <jengelh@inai.de> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-03-30 06:27:50 +04:00
*** is installed and then try again. If that fails, you can specify the
Verify --with-linux source directory exists Previously this check was only performed when ./configure was attempting to autodetect your kernel source directory. But we should also handle the case where --with-linux was provided and is obviously wrong. This way we catch the error before invoking make and compiling the source with an incorrect autoconf results. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #162
2012-11-30 07:26:19 +04:00
*** location of the kernel source with the '--with-linux=PATH' option.])
fi
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
AC_MSG_CHECKING([kernel build directory])
Packaging improvements for RHEL and SLES - Properly honor --prefix in build system and rpm spec file. - Add '--define require_kdir' to spec file to support building rpms against kernel sources installed in non-default locations. - Add '--define require_kobj' to spec file to support building rpms against kernel object installed in non-default locations. - Stop suppressing errors in autogen.sh script. - Improved logic to detect missing kernel objects when they are not located with the source. This is the common case for SLES as well as in-tree chaos kernel builds and is done to simply support for multiple arches. - Moved spl-devel build products to /usr/src/spl-<version>, a spl symlink is created to reference the last installed version.
2009-06-16 21:44:59 +04:00
if test -z "$kernelbuild"; then
Prefer /lib/modules/$(uname -r)/ links Preferentially use the /lib/modules/$(uname -r)/source and /lib/modules/$(uname -r)/build links. Only if neither of these links exist fallback to alternate methods for deducing which kernel to build with. This resolves the need to manually specify --with-linux= and --with-linux-obj= on Debian systems.
2011-02-11 01:40:57 +03:00
if test -e "/lib/modules/$(uname -r)/build"; then
kernelbuild=`readlink -f /lib/modules/$(uname -r)/build`
elif test -d ${kernelsrc}-obj/${target_cpu}/${target_cpu}; then
Use $target_cpu instead of `arch` We should not be using arch for a few reasons. First off it might not be installed on their system, and secondly they may be trying to cross-compile.
2010-07-02 00:27:30 +04:00
kernelbuild=${kernelsrc}-obj/${target_cpu}/${target_cpu}
elif test -d ${kernelsrc}-obj/${target_cpu}/default; then
kernelbuild=${kernelsrc}-obj/${target_cpu}/default
elif test -d `dirname ${kernelsrc}`/build-${target_cpu}; then
kernelbuild=`dirname ${kernelsrc}`/build-${target_cpu}
Packaging improvements for RHEL and SLES - Properly honor --prefix in build system and rpm spec file. - Add '--define require_kdir' to spec file to support building rpms against kernel sources installed in non-default locations. - Add '--define require_kobj' to spec file to support building rpms against kernel object installed in non-default locations. - Stop suppressing errors in autogen.sh script. - Improved logic to detect missing kernel objects when they are not located with the source. This is the common case for SLES as well as in-tree chaos kernel builds and is done to simply support for multiple arches. - Moved spl-devel build products to /usr/src/spl-<version>, a spl symlink is created to reference the last installed version.
2009-06-16 21:44:59 +04:00
else
kernelbuild=${kernelsrc}
fi
SLES10 Fixes (part 1): - Exclude -obj when detecting installed kernel source. - Detect -obj directory for out of tree kernel builds. - Allow kernel build system to set CC to ensure -m64 is set properly. This is an issue on 64-bit SLES systems which by default always build 32-bit binaries (unlike RHEL/Fedora which default to 64-bit)
2009-05-19 22:42:39 +04:00
fi
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
AC_MSG_RESULT([$kernelbuild])
AC_MSG_CHECKING([kernel source version])
Linux-2.6.33 compat, check <generated/utsrelease.h> for UTS_RELEASE It seems the upstream community moved the definition of UTS_RELEASE yet again as of linux-2.6.33. Update the build system to check in all three possible locations where your kernel version may be defined. $kernelbuild/include/linux/version.h $kernelbuild/include/linux/utsrelease.h $kernelbuild/include/generated/utsrelease.h
2010-06-30 20:47:57 +04:00
utsrelease1=$kernelbuild/include/linux/version.h
utsrelease2=$kernelbuild/include/linux/utsrelease.h
utsrelease3=$kernelbuild/include/generated/utsrelease.h
if test -r $utsrelease1 && fgrep -q UTS_RELEASE $utsrelease1; then
utsrelease=linux/version.h
elif test -r $utsrelease2 && fgrep -q UTS_RELEASE $utsrelease2; then
utsrelease=linux/utsrelease.h
elif test -r $utsrelease3 && fgrep -q UTS_RELEASE $utsrelease3; then
utsrelease=generated/utsrelease.h
fi
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
Linux-2.6.33 compat, check <generated/utsrelease.h> for UTS_RELEASE It seems the upstream community moved the definition of UTS_RELEASE yet again as of linux-2.6.33. Update the build system to check in all three possible locations where your kernel version may be defined. $kernelbuild/include/linux/version.h $kernelbuild/include/linux/utsrelease.h $kernelbuild/include/generated/utsrelease.h
2010-06-30 20:47:57 +04:00
if test "$utsrelease"; then
kernsrcver=`(echo "#include <$utsrelease>";
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
echo "kernsrcver=UTS_RELEASE") |
Build System Default Kernel Update the method used for determining which kernel to build against when not specified. Previous 'uname -r' was used but this makes the assumption that the running kernel is the one you want to use, this is often not the case. It is better to examine the usual kernel-devel install locations and select one of the installed kernels.
2009-03-10 02:50:37 +03:00
cpp -I $kernelbuild/include |
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
grep "^kernsrcver=" | cut -d \" -f 2`
Linux-2.6.33 compat, check <generated/utsrelease.h> for UTS_RELEASE It seems the upstream community moved the definition of UTS_RELEASE yet again as of linux-2.6.33. Update the build system to check in all three possible locations where your kernel version may be defined. $kernelbuild/include/linux/version.h $kernelbuild/include/linux/utsrelease.h $kernelbuild/include/generated/utsrelease.h
2010-06-30 20:47:57 +04:00
if test -z "$kernsrcver"; then
AC_MSG_RESULT([Not found])
AC_MSG_ERROR([*** Cannot determine kernel version.])
fi
else
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
AC_MSG_RESULT([Not found])
Make configure builtin-aware. This patch adds a new option to configure: --enable-linux-builtin. When this option is used, the following happens: - Compilation of kernel modules is disabled. - A failure to find UTS_RELEASE is followed by a suggestion to run "make prepare" on the kernel source tree. This patch also adds a new test which tries to compile an empty module as a basic toolchain sanity test. If it fails and the option was specified, the error is followed by a suggestion to run "make scripts" on the kernel source tree. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 18:34:43 +04:00
if test "x$enable_linux_builtin" != xyes; then
AC_MSG_ERROR([*** Cannot find UTS_RELEASE definition.])
else
AC_MSG_ERROR([
*** Cannot find UTS_RELEASE definition.
*** Please run 'make prepare' inside the kernel source tree.])
fi
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
fi
AC_MSG_RESULT([$kernsrcver])
LINUX=${kernelsrc}
LINUX_OBJ=${kernelbuild}
Build system and packaging (RPM support) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild spl-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all spl modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the spl. spl-x.y.z-1_<kernel version>.x86_64.rpm spl-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-05 20:08:07 +03:00
LINUX_VERSION=${kernsrcver}
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
AC_SUBST(LINUX)
AC_SUBST(LINUX_OBJ)
Build system and packaging (RPM support) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild spl-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all spl modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the spl. spl-x.y.z-1_<kernel version>.x86_64.rpm spl-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-05 20:08:07 +03:00
AC_SUBST(LINUX_VERSION)
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
SPL_AC_MODULE_SYMVERS
Packaging improvements for RHEL and SLES (part 2) - Allow checking for exported symbols in both Module.symvers and Module.symvers. My stock SLES kernel ships an objects directory with Module.symvers, yet produces a Module.symvers in the local build directory.
2009-06-16 22:34:28 +04:00
])
Add Debian and Slackware style packaging via alien The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.
2010-07-27 21:19:44 +04:00
dnl #
dnl # Default SPL user configuration
dnl #
Remove the gawk dependency. This reverts commit 1814251453c8140f50170ad29d9105c1273d7e08. Demote the gawk call back to awk and ensure that stderr is attached. GNU gawk tolerates a missing stderr handle, but many utilities do not, which could be why a regular awk call was unexplainably failing on some systems. Use argv[0] instead of sh_path for consistency internally and with other Linux drivers. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2011-04-14 23:01:22 +04:00
AC_DEFUN([SPL_AC_CONFIG_USER], [])
Add Debian and Slackware style packaging via alien The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.
2010-07-27 21:19:44 +04:00
dnl #
dnl # Check for rpm+rpmbuild to build RPM packages. If these tools
build: resolve orthographic and other grammatical errors Signed-off-by: Jan Engelhardt <jengelh@inai.de> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-03-30 06:27:50 +04:00
dnl # are missing, it is non-fatal, but you will not be able to build
Add Debian and Slackware style packaging via alien The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.
2010-07-27 21:19:44 +04:00
dnl # RPM packages and will be warned if you try too.
dnl #
build: resolve orthographic and other grammatical errors Signed-off-by: Jan Engelhardt <jengelh@inai.de> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-03-30 06:27:50 +04:00
dnl # By default, the generic spec file will be used because it requires
Refresh RPM packaging Refresh the existing RPM packaging to conform to the 'Fedora Packaging Guidelines'. This includes adopting the kmods2 packaging standard which is used fod kmods distributed by rpmfusion for Fedora/RHEL. http://fedoraproject.org/wiki/Packaging:Guidelines http://rpmfusion.org/Packaging/KernelModules/Kmods2 While the spec files have been entirely rewritten from a user perspective the only major changes are: * The Fedora packages now have a build dependency on the rpmfusion repositories. The generic kmod packages also have a new dependency on kmodtool-1.22 but it is bundled with the source rpm so no additional packages are needed. * The kernel binary module packages have been renamed from spl-modules-* to kmod-spl-* as specificed by kmods2. * The is now a common kmod-spl-devel-* package in addition to the per-kernel devel packages. The common package contains the development headers while the per-kernel package contains kernel specific build products. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #222
2013-02-08 23:02:08 +04:00
dnl # minimal dependencies. Distribution specific spec files can be
dnl # placed under the 'rpm/<distribution>' directory and enabled using
dnl # the --with-spec=<distribution> configure option.
dnl #
Add Debian and Slackware style packaging via alien The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.
2010-07-27 21:19:44 +04:00
AC_DEFUN([SPL_AC_RPM], [
RPM=rpm
RPMBUILD=rpmbuild
AC_MSG_CHECKING([whether $RPM is available])
AS_IF([tmp=$($RPM --version 2>/dev/null)], [
RPM_VERSION=$(echo $tmp | $AWK '/RPM/ { print $[3] }')
HAVE_RPM=yes
AC_MSG_RESULT([$HAVE_RPM ($RPM_VERSION)])
],[
HAVE_RPM=no
AC_MSG_RESULT([$HAVE_RPM])
])
AC_MSG_CHECKING([whether $RPMBUILD is available])
AS_IF([tmp=$($RPMBUILD --version 2>/dev/null)], [
RPMBUILD_VERSION=$(echo $tmp | $AWK '/RPM/ { print $[3] }')
HAVE_RPMBUILD=yes
AC_MSG_RESULT([$HAVE_RPMBUILD ($RPMBUILD_VERSION)])
],[
HAVE_RPMBUILD=no
AC_MSG_RESULT([$HAVE_RPMBUILD])
])
Refresh RPM packaging Refresh the existing RPM packaging to conform to the 'Fedora Packaging Guidelines'. This includes adopting the kmods2 packaging standard which is used fod kmods distributed by rpmfusion for Fedora/RHEL. http://fedoraproject.org/wiki/Packaging:Guidelines http://rpmfusion.org/Packaging/KernelModules/Kmods2 While the spec files have been entirely rewritten from a user perspective the only major changes are: * The Fedora packages now have a build dependency on the rpmfusion repositories. The generic kmod packages also have a new dependency on kmodtool-1.22 but it is bundled with the source rpm so no additional packages are needed. * The kernel binary module packages have been renamed from spl-modules-* to kmod-spl-* as specificed by kmods2. * The is now a common kmod-spl-devel-* package in addition to the per-kernel devel packages. The common package contains the development headers while the per-kernel package contains kernel specific build products. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #222
2013-02-08 23:02:08 +04:00
RPM_DEFINE_COMMON='--define "$(DEBUG_SPL) 1" --define "$(DEBUG_LOG) 1" --define "$(DEBUG_KMEM) 1" --define "$(DEBUG_KMEM_TRACKING) 1"'
RPM_DEFINE_UTIL=
RPM_DEFINE_KMOD='--define "kernels $(LINUX_VERSION)"'
RPM_DEFINE_DKMS=
SRPM_DEFINE_COMMON='--define "build_src_rpm 1"'
SRPM_DEFINE_UTIL=
SRPM_DEFINE_KMOD=
SRPM_DEFINE_DKMS=
RPM_SPEC_DIR="rpm/generic"
AC_ARG_WITH([spec],
AS_HELP_STRING([--with-spec=SPEC],
[Spec files 'generic|fedora']),
[RPM_SPEC_DIR="rpm/$withval"])
AC_MSG_CHECKING([whether spec files are available])
AC_MSG_RESULT([yes ($RPM_SPEC_DIR/*.spec.in)])
Add Debian and Slackware style packaging via alien The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.
2010-07-27 21:19:44 +04:00
AC_SUBST(HAVE_RPM)
AC_SUBST(RPM)
AC_SUBST(RPM_VERSION)
AC_SUBST(HAVE_RPMBUILD)
AC_SUBST(RPMBUILD)
AC_SUBST(RPMBUILD_VERSION)
Refresh RPM packaging Refresh the existing RPM packaging to conform to the 'Fedora Packaging Guidelines'. This includes adopting the kmods2 packaging standard which is used fod kmods distributed by rpmfusion for Fedora/RHEL. http://fedoraproject.org/wiki/Packaging:Guidelines http://rpmfusion.org/Packaging/KernelModules/Kmods2 While the spec files have been entirely rewritten from a user perspective the only major changes are: * The Fedora packages now have a build dependency on the rpmfusion repositories. The generic kmod packages also have a new dependency on kmodtool-1.22 but it is bundled with the source rpm so no additional packages are needed. * The kernel binary module packages have been renamed from spl-modules-* to kmod-spl-* as specificed by kmods2. * The is now a common kmod-spl-devel-* package in addition to the per-kernel devel packages. The common package contains the development headers while the per-kernel package contains kernel specific build products. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #222
2013-02-08 23:02:08 +04:00
AC_SUBST(RPM_SPEC_DIR)
AC_SUBST(RPM_DEFINE_UTIL)
AC_SUBST(RPM_DEFINE_KMOD)
AC_SUBST(RPM_DEFINE_DKMS)
AC_SUBST(RPM_DEFINE_COMMON)
AC_SUBST(SRPM_DEFINE_UTIL)
AC_SUBST(SRPM_DEFINE_KMOD)
AC_SUBST(SRPM_DEFINE_DKMS)
AC_SUBST(SRPM_DEFINE_COMMON)
Add Debian and Slackware style packaging via alien The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.
2010-07-27 21:19:44 +04:00
])
dnl #
dnl # Check for dpkg+dpkg-buildpackage to build DEB packages. If these
dnl # tools are missing it is non-fatal but you will not be able to build
dnl # DEB packages and will be warned if you try too.
dnl #
AC_DEFUN([SPL_AC_DPKG], [
DPKG=dpkg
DPKGBUILD=dpkg-buildpackage
AC_MSG_CHECKING([whether $DPKG is available])
AS_IF([tmp=$($DPKG --version 2>/dev/null)], [
DPKG_VERSION=$(echo $tmp | $AWK '/Debian/ { print $[7] }')
HAVE_DPKG=yes
AC_MSG_RESULT([$HAVE_DPKG ($DPKG_VERSION)])
],[
HAVE_DPKG=no
AC_MSG_RESULT([$HAVE_DPKG])
])
AC_MSG_CHECKING([whether $DPKGBUILD is available])
AS_IF([tmp=$($DPKGBUILD --version 2>/dev/null)], [
DPKGBUILD_VERSION=$(echo $tmp | \
$AWK '/Debian/ { print $[4] }' | cut -f-4 -d'.')
HAVE_DPKGBUILD=yes
AC_MSG_RESULT([$HAVE_DPKGBUILD ($DPKGBUILD_VERSION)])
],[
HAVE_DPKGBUILD=no
AC_MSG_RESULT([$HAVE_DPKGBUILD])
])
AC_SUBST(HAVE_DPKG)
AC_SUBST(DPKG)
AC_SUBST(DPKG_VERSION)
AC_SUBST(HAVE_DPKGBUILD)
AC_SUBST(DPKGBUILD)
AC_SUBST(DPKGBUILD_VERSION)
])
dnl #
dnl # Until native packaging for various different packing systems
dnl # can be added the least we can do is attempt to use alien to
dnl # convert the RPM packages to the needed package type. This is
dnl # a hack but so far it has worked reasonable well.
dnl #
AC_DEFUN([SPL_AC_ALIEN], [
ALIEN=alien
AC_MSG_CHECKING([whether $ALIEN is available])
AS_IF([tmp=$($ALIEN --version 2>/dev/null)], [
ALIEN_VERSION=$(echo $tmp | $AWK '{ print $[3] }')
HAVE_ALIEN=yes
AC_MSG_RESULT([$HAVE_ALIEN ($ALIEN_VERSION)])
],[
HAVE_ALIEN=no
AC_MSG_RESULT([$HAVE_ALIEN])
])
AC_SUBST(HAVE_ALIEN)
AC_SUBST(ALIEN)
AC_SUBST(ALIEN_VERSION)
])
dnl #
dnl # Using the VENDOR tag from config.guess set the default
dnl # package type for 'make pkg': (rpm | deb | tgz)
dnl #
AC_DEFUN([SPL_AC_DEFAULT_PACKAGE], [
Move vendor check to spl-build.m4 This check was previously done with a hack in config.guess. However, since a new config.guess is copied in to place when forcing a full autoreconf this change was easily lost and never a good idea. This commit also updates all of the autoconf style support scripts in config.
2010-09-03 02:39:08 +04:00
AC_MSG_CHECKING([linux distribution])
Fix distribution detection Improve the distribution detection by moving the tests for distribution specific files first. The Ubuntu and Debian checks are left for last because they are the least likely to be unique. This is particularly true in the case of Debian since so many distributions are based on Debian. Since this is currently only used to identify the correct packaging method for this system the result in many instances is simply cosmetic. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-03-05 22:22:23 +04:00
if test -f /etc/toss-release ; then
VENDOR=toss ;
Move vendor check to spl-build.m4 This check was previously done with a hack in config.guess. However, since a new config.guess is copied in to place when forcing a full autoreconf this change was easily lost and never a good idea. This commit also updates all of the autoconf style support scripts in config.
2010-09-03 02:39:08 +04:00
elif test -f /etc/fedora-release ; then
VENDOR=fedora ;
Fix distribution detection Improve the distribution detection by moving the tests for distribution specific files first. The Ubuntu and Debian checks are left for last because they are the least likely to be unique. This is particularly true in the case of Debian since so many distributions are based on Debian. Since this is currently only used to identify the correct packaging method for this system the result in many instances is simply cosmetic. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-03-05 22:22:23 +04:00
elif test -f /etc/redhat-release ; then
VENDOR=redhat ;
elif test -f /etc/gentoo-release ; then
VENDOR=gentoo ;
Move Arch Linux's VENDOR check above Ubuntu's If the lsb-release package is installed on an Arch Linux distribution, the configure step will incorrectly detect the running distribution as Ubuntu. This is a result of both distributions providing an /etc/lsb-release file, and the Ubuntu VENDOR check being performed first. Since the Arch Linux test check's for a file more specific to the Arch Linux distribution, moving Arch Linux's VENDOR check above Unbuntu's check provides a quick and easy solution. Signed-off-by: Prakash Surya <surya1@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #72
2011-12-17 10:16:47 +04:00
elif test -f /etc/arch-release ; then
VENDOR=arch ;
Move vendor check to spl-build.m4 This check was previously done with a hack in config.guess. However, since a new config.guess is copied in to place when forcing a full autoreconf this change was easily lost and never a good idea. This commit also updates all of the autoconf style support scripts in config.
2010-09-03 02:39:08 +04:00
elif test -f /etc/SuSE-release ; then
VENDOR=sles ;
elif test -f /etc/slackware-version ; then
VENDOR=slackware ;
Fix distribution detection Improve the distribution detection by moving the tests for distribution specific files first. The Ubuntu and Debian checks are left for last because they are the least likely to be unique. This is particularly true in the case of Debian since so many distributions are based on Debian. Since this is currently only used to identify the correct packaging method for this system the result in many instances is simply cosmetic. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-03-05 22:22:23 +04:00
elif test -f /etc/lunar.release ; then
VENDOR=lunar ;
elif test -f /etc/lsb-release ; then
VENDOR=ubuntu ;
elif test -f /etc/debian_version ; then
VENDOR=debian ;
Move vendor check to spl-build.m4 This check was previously done with a hack in config.guess. However, since a new config.guess is copied in to place when forcing a full autoreconf this change was easily lost and never a good idea. This commit also updates all of the autoconf style support scripts in config.
2010-09-03 02:39:08 +04:00
else
VENDOR= ;
fi
AC_MSG_RESULT([$VENDOR])
AC_SUBST(VENDOR)
Add Debian and Slackware style packaging via alien The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.
2010-07-27 21:19:44 +04:00
AC_MSG_CHECKING([default package type])
case "$VENDOR" in
Fix distribution detection Improve the distribution detection by moving the tests for distribution specific files first. The Ubuntu and Debian checks are left for last because they are the least likely to be unique. This is particularly true in the case of Debian since so many distributions are based on Debian. Since this is currently only used to identify the correct packaging method for this system the result in many instances is simply cosmetic. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-03-05 22:22:23 +04:00
toss) DEFAULT_PACKAGE=rpm ;;
redhat) DEFAULT_PACKAGE=rpm ;;
fedora) DEFAULT_PACKAGE=rpm ;;
gentoo) DEFAULT_PACKAGE=tgz ;;
Remove ARCH packaging The kernel modules are now available in the Arch User Repository (AUR) via zfs. Since their packaging is maintained and superior to ours it is being removed from the tree. https://wiki.archlinux.org/index.php/ZFS Now that various distributions are picking up the packages we should eventually be able to remove most of this infrastructure. Packaging belongs with the distributions not upstream. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-02-17 03:32:08 +04:00
arch) DEFAULT_PACKAGE=tgz ;;
Fix distribution detection Improve the distribution detection by moving the tests for distribution specific files first. The Ubuntu and Debian checks are left for last because they are the least likely to be unique. This is particularly true in the case of Debian since so many distributions are based on Debian. Since this is currently only used to identify the correct packaging method for this system the result in many instances is simply cosmetic. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-03-05 22:22:23 +04:00
sles) DEFAULT_PACKAGE=rpm ;;
slackware) DEFAULT_PACKAGE=tgz ;;
lunar) DEFAULT_PACKAGE=tgz ;;
ubuntu) DEFAULT_PACKAGE=deb ;;
debian) DEFAULT_PACKAGE=deb ;;
*) DEFAULT_PACKAGE=rpm ;;
Add Debian and Slackware style packaging via alien The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.
2010-07-27 21:19:44 +04:00
esac
AC_MSG_RESULT([$DEFAULT_PACKAGE])
AC_SUBST(DEFAULT_PACKAGE)
])
dnl #
dnl # Default SPL user configuration
dnl #
AC_DEFUN([SPL_AC_PACKAGE], [
Run SPL_AC_PACMAN only if $VENDOR is "arch" Unfortunately, Arch's package manager `pacman` shares it's name with a popular arcade video game. Thus, in order to refrain from executing the video game when we mean to execute the package manager, SPL_AC_PACMAN is now only run when $VENDOR is determined to be "arch". Signed-off-by: Prakash Surya <surya1@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#517
2012-01-13 21:08:12 +04:00
SPL_AC_DEFAULT_PACKAGE
Add Debian and Slackware style packaging via alien The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.
2010-07-27 21:19:44 +04:00
SPL_AC_RPM
SPL_AC_DPKG
SPL_AC_ALIEN
])
* include/sys/sunddi.h, modules/spl/spl-module.c : Removed default udev support from sunddi implementation because it uses GPL-only symbols. This support is optionally available for SPL consumers if they define HAVE_GPL_ONLY_SYMBOLS and license their module as GPL using the MODULE_LICENSE("GPL") macro. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@179 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-14 00:43:30 +03:00
AC_DEFUN([SPL_AC_LICENSE], [
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
AC_MSG_CHECKING([spl license])
LICENSE=GPL
AC_MSG_RESULT([$LICENSE])
* include/sys/sunddi.h, modules/spl/spl-module.c : Removed default udev support from sunddi implementation because it uses GPL-only symbols. This support is optionally available for SPL consumers if they define HAVE_GPL_ONLY_SYMBOLS and license their module as GPL using the MODULE_LICENSE("GPL") macro. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@179 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-14 00:43:30 +03:00
KERNELCPPFLAGS="${KERNELCPPFLAGS} -DHAVE_GPL_ONLY_SYMBOLS"
Simplify rpm build rules, added config/rpm.am. Distro friendly changes such that the kernel modules are packaged seperately.
2009-07-02 01:37:44 +04:00
AC_SUBST(LICENSE)
])
AC_DEFUN([SPL_AC_CONFIG], [
Make configure builtin-aware. This patch adds a new option to configure: --enable-linux-builtin. When this option is used, the following happens: - Compilation of kernel modules is disabled. - A failure to find UTS_RELEASE is followed by a suggestion to run "make prepare" on the kernel source tree. This patch also adds a new test which tries to compile an empty module as a basic toolchain sanity test. If it fails and the option was specified, the error is followed by a suggestion to run "make scripts" on the kernel source tree. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 18:34:43 +04:00
SPL_CONFIG=all
AC_ARG_WITH([config],
AS_HELP_STRING([--with-config=CONFIG],
[Config file 'kernel|user|all|srpm']),
[SPL_CONFIG="$withval"])
AC_ARG_ENABLE([linux-builtin],
[AC_HELP_STRING([--enable-linux-builtin],
[Configure for builtin in-tree kernel modules @<:@default=no@:>@])],
[],
[enable_linux_builtin=no])
AC_MSG_CHECKING([spl config])
AC_MSG_RESULT([$SPL_CONFIG]);
AC_SUBST(SPL_CONFIG)
case "$SPL_CONFIG" in
kernel) SPL_AC_CONFIG_KERNEL ;;
user) SPL_AC_CONFIG_USER ;;
all) SPL_AC_CONFIG_KERNEL
SPL_AC_CONFIG_USER ;;
Add 'srpm' --with-config option for creation of spec files.
2009-11-25 01:21:45 +03:00
srpm) ;;
Make configure builtin-aware. This patch adds a new option to configure: --enable-linux-builtin. When this option is used, the following happens: - Compilation of kernel modules is disabled. - A failure to find UTS_RELEASE is followed by a suggestion to run "make prepare" on the kernel source tree. This patch also adds a new test which tries to compile an empty module as a basic toolchain sanity test. If it fails and the option was specified, the error is followed by a suggestion to run "make scripts" on the kernel source tree. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 18:34:43 +04:00
*)
AC_MSG_RESULT([Error!])
AC_MSG_ERROR([Bad value "$SPL_CONFIG" for --with-config,
user kernel|user|all|srpm]) ;;
esac
AM_CONDITIONAL([CONFIG_USER],
[test "$SPL_CONFIG" = user -o "$SPL_CONFIG" = all])
AM_CONDITIONAL([CONFIG_KERNEL],
[test "$SPL_CONFIG" = kernel -o "$SPL_CONFIG" = all] &&
[test "x$enable_linux_builtin" != xyes ])
* include/sys/sunddi.h, modules/spl/spl-module.c : Removed default udev support from sunddi implementation because it uses GPL-only symbols. This support is optionally available for SPL consumers if they define HAVE_GPL_ONLY_SYMBOLS and license their module as GPL using the MODULE_LICENSE("GPL") macro. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@179 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-14 00:43:30 +03:00
])
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
dnl #
dnl # Enable if the SPL should be compiled with internal debugging enabled.
dnl # By default this support is disabled.
dnl #
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
AC_DEFUN([SPL_AC_DEBUG], [
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-01 04:05:36 +04:00
AC_MSG_CHECKING([whether debugging is enabled])
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
AC_ARG_ENABLE([debug],
[AS_HELP_STRING([--enable-debug],
[Enable generic debug support @<:@default=no@:>@])],
[],
[enable_debug=no])
AS_IF([test "x$enable_debug" = xyes],
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-01 04:05:36 +04:00
[
KERNELCPPFLAGS="${KERNELCPPFLAGS} -DDEBUG -Werror"
DEBUG_CFLAGS="-DDEBUG -Werror"
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
DEBUG_SPL="_with_debug"
], [
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-01 04:05:36 +04:00
KERNELCPPFLAGS="${KERNELCPPFLAGS} -DNDEBUG"
DEBUG_CFLAGS="-DNDEBUG"
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
DEBUG_SPL="_without_debug"
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-01 04:05:36 +04:00
])
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
Only make compiler warnings fatal with --enable-debug While in theory I like the idea of compiler warnings always being fatal. In practice this causes problems when small harmless errors cause build failures for end users. To handle this I've updated the build system such that -Werror is only used when --enable-debug is passed to configure. This is how I always build when developing so I'll catch all build warnings and end users will not get stuck by minor issues.
2010-07-01 04:05:36 +04:00
AC_SUBST(DEBUG_CFLAGS)
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
AC_SUBST(DEBUG_SPL)
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
AC_MSG_RESULT([$enable_debug])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
])
Add --enable-debug-log configure option Until now the notion of an internal debug logging infrastructure was conflated with enabling ASSERT()s. This patch clarifies things by cleanly breaking the two subsystem apart. The result of this is the following behavior. --enable-debug - Enable/disable code wrapped in ASSERT()s. --disable-debug ASSERT()s are used to check invariants and are never required for correct operation. They are disabled by default because they may impact performance. --enable-debug-log - Enable/disable the debug log infrastructure. --disable-debug-log This infrastructure allows the spl code and its consumer to log messages to an in-kernel log. The granularity of the logging can be controlled by a debug mask. By default the mask disables most debug messages resulting in a negligible performance impact. Because of this the debug log is enabled by default. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-01-21 04:39:12 +04:00
dnl #
dnl # Enabled by default it provides a basic debug log infrastructure.
dnl # Each subsystem registers itself with a name and logs messages
dnl # using predefined types. If the debug mask it set to allow the
dnl # message type it will be written to the internal log. The log
dnl # can be dumped to a file by echoing 1 to the 'dump' proc entry,
dnl # after dumping the log it must be decoded using the spl utility.
dnl #
dnl # echo 1 >/proc/sys/kernel/spl/debug/dump
dnl # spl /tmp/spl-log.xxx.yyy /tmp/spl-log.xxx.yyy.txt
dnl #
AC_DEFUN([SPL_AC_DEBUG_LOG], [
AC_ARG_ENABLE([debug-log],
[AS_HELP_STRING([--enable-debug-log],
[Enable basic debug logging @<:@default=yes@:>@])],
[],
[enable_debug_log=yes])
AS_IF([test "x$enable_debug_log" = xyes],
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
[
KERNELCPPFLAGS="${KERNELCPPFLAGS} -DDEBUG_LOG"
DEBUG_LOG="_with_debug_log"
AC_DEFINE([DEBUG_LOG], [1],
Add --enable-debug-log configure option Until now the notion of an internal debug logging infrastructure was conflated with enabling ASSERT()s. This patch clarifies things by cleanly breaking the two subsystem apart. The result of this is the following behavior. --enable-debug - Enable/disable code wrapped in ASSERT()s. --disable-debug ASSERT()s are used to check invariants and are never required for correct operation. They are disabled by default because they may impact performance. --enable-debug-log - Enable/disable the debug log infrastructure. --disable-debug-log This infrastructure allows the spl code and its consumer to log messages to an in-kernel log. The granularity of the logging can be controlled by a debug mask. By default the mask disables most debug messages resulting in a negligible performance impact. Because of this the debug log is enabled by default. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-01-21 04:39:12 +04:00
[Define to 1 to enable basic debug logging])
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
], [
DEBUG_LOG="_without_debug_log"
])
Add --enable-debug-log configure option Until now the notion of an internal debug logging infrastructure was conflated with enabling ASSERT()s. This patch clarifies things by cleanly breaking the two subsystem apart. The result of this is the following behavior. --enable-debug - Enable/disable code wrapped in ASSERT()s. --disable-debug ASSERT()s are used to check invariants and are never required for correct operation. They are disabled by default because they may impact performance. --enable-debug-log - Enable/disable the debug log infrastructure. --disable-debug-log This infrastructure allows the spl code and its consumer to log messages to an in-kernel log. The granularity of the logging can be controlled by a debug mask. By default the mask disables most debug messages resulting in a negligible performance impact. Because of this the debug log is enabled by default. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-01-21 04:39:12 +04:00
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
AC_SUBST(DEBUG_LOG)
Add --enable-debug-log configure option Until now the notion of an internal debug logging infrastructure was conflated with enabling ASSERT()s. This patch clarifies things by cleanly breaking the two subsystem apart. The result of this is the following behavior. --enable-debug - Enable/disable code wrapped in ASSERT()s. --disable-debug ASSERT()s are used to check invariants and are never required for correct operation. They are disabled by default because they may impact performance. --enable-debug-log - Enable/disable the debug log infrastructure. --disable-debug-log This infrastructure allows the spl code and its consumer to log messages to an in-kernel log. The granularity of the logging can be controlled by a debug mask. By default the mask disables most debug messages resulting in a negligible performance impact. Because of this the debug log is enabled by default. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-01-21 04:39:12 +04:00
AC_MSG_CHECKING([whether basic debug logging is enabled])
AC_MSG_RESULT([$enable_debug_log])
])
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
dnl #
dnl # Enabled by default it provides a minimal level of memory tracking.
dnl # A total count of bytes allocated is kept for each alloc and free.
dnl # Then at module unload time a report to the console will be printed
dnl # if memory was leaked. Additionally, /proc/spl/kmem/slab will exist
dnl # and provide an easy way to inspect the kmem based slab.
dnl #
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
AC_DEFUN([SPL_AC_DEBUG_KMEM], [
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
AC_ARG_ENABLE([debug-kmem],
[AS_HELP_STRING([--enable-debug-kmem],
[Enable basic kmem accounting @<:@default=yes@:>@])],
[],
[enable_debug_kmem=yes])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
AS_IF([test "x$enable_debug_kmem" = xyes],
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
[
KERNELCPPFLAGS="${KERNELCPPFLAGS} -DDEBUG_KMEM"
DEBUG_KMEM="_with_debug_kmem"
AC_DEFINE([DEBUG_KMEM], [1],
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
[Define to 1 to enable basic kmem accounting])
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
], [
DEBUG_KMEM="_without_debug_kmem"
])
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
AC_SUBST(DEBUG_KMEM)
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
AC_MSG_CHECKING([whether basic kmem accounting is enabled])
AC_MSG_RESULT([$enable_debug_kmem])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
])
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
dnl #
dnl # Disabled by default it provides detailed memory tracking. This
dnl # feature also requires --enable-debug-kmem to be set. When enabled
dnl # not only will total bytes be tracked but also the location of every
dnl # alloc and free. When the SPL module is unloaded a list of all leaked
dnl # addresses and where they were allocated will be dumped to the console.
dnl # Enabling this feature has a significant impact on performance but it
dnl # makes finding memory leaks pretty straight forward.
dnl #
AC_DEFUN([SPL_AC_DEBUG_KMEM_TRACKING], [
AC_ARG_ENABLE([debug-kmem-tracking],
[AS_HELP_STRING([--enable-debug-kmem-tracking],
[Enable detailed kmem tracking @<:@default=no@:>@])],
[],
[enable_debug_kmem_tracking=no])
AS_IF([test "x$enable_debug_kmem_tracking" = xyes],
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
[
KERNELCPPFLAGS="${KERNELCPPFLAGS} -DDEBUG_KMEM_TRACKING"
DEBUG_KMEM_TRACKING="_with_debug_kmem_tracking"
AC_DEFINE([DEBUG_KMEM_TRACKING], [1],
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
[Define to 1 to enable detailed kmem tracking])
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
], [
DEBUG_KMEM_TRACKING="_without_debug_kmem_tracking"
])
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
Cleanly support debug packages Allow a source rpm to be rebuilt with debugging enabled. This avoids the need to have to manually modify the spec file. By default debugging is still largely disabled. To enable specific debugging features use the following options with rpmbuild. '--with debug' - Enables ASSERTs '--with debug-log' - Enables the internal debug log '--with debug-kmem' - Enables basic memory accounting '--with debug-kmem-tracking' - Enables detailed memory tracking # For example: $ rpmbuild --rebuild --with debug spl-modules-0.6.0-rc6.src.rpm Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2012-02-27 22:42:07 +04:00
AC_SUBST(DEBUG_KMEM_TRACKING)
Autoconf --enable-debug-* cleanup Cleanup the --enable-debug-* configure options, this has been pending for quite some time and I am glad I finally got to it. To summerize: 1) All SPL_AC_DEBUG_* macros were updated to be a more autoconf friendly. This mainly involved shift to the GNU approved usage of AC_ARG_ENABLE and ensuring AS_IF is used rather than directly using an if [ test ] construct. 2) --enable-debug-kmem=yes by default. This simply enabled keeping a running tally of total memory allocated and freed and reporting a memory leak if there was one at module unload. Additionally, it ensure /proc/spl/kmem/slab will exist by default which is handy. The overhead is low for this and it should not impact performance. 3) --enable-debug-kmem-tracking=no by default. This option was added to provide a configure option to enable to detailed memory allocation tracking. This support was always there but you had to know where to turn it on. By default this support is disabled because it is known to badly hurt performence, however it is invaluable when chasing a memory leak. 4) --enable-debug-kstat removed. After further reflection I can't see why you would ever really want to turn this support off. It is now always on which had the nice side effect of simplifying the proc handling code in spl-proc.c. We can now always assume the top level directory will be there. 5) --enable-debug-callb removed. This never really did anything, it was put in provisionally because it might have been needed. It turns out it was not so I am just removing it to prevent confusion.
2009-10-30 23:58:51 +03:00
AC_MSG_CHECKING([whether detailed kmem tracking is enabled])
AC_MSG_RESULT([$enable_debug_kmem_tracking])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
])
dnl #
dnl # SPL_LINUX_CONFTEST
dnl #
AC_DEFUN([SPL_LINUX_CONFTEST], [
Allow config/build to work with autoconf-2.65 As of autoconf-2.65 the AC_LANG_SOURCE source macro no longer includes the confdef.h results when expanded. To handle this simply explicitly include confdef.h in conftest.c. This will cause two copies to of confdef.h to be added to the test for earlier autoconf versions but this is not harmful. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2010-07-01 12:39:32 +04:00
cat confdefs.h - <<_ACEOF >conftest.c
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
$1
_ACEOF
])
dnl #
dnl # SPL_LANG_PROGRAM(C)([PROLOGUE], [BODY])
dnl #
m4_define([SPL_LANG_PROGRAM], [
$1
int
main (void)
{
dnl Do *not* indent the following line: there may be CPP directives.
dnl Don't move the `;' right after for the same reason.
$2
;
return 0;
}
])
dnl #
dnl # SPL_LINUX_COMPILE_IFELSE / like AC_COMPILE_IFELSE
dnl #
AC_DEFUN([SPL_LINUX_COMPILE_IFELSE], [
Build system and packaging (RPM support) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild spl-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all spl modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the spl. spl-x.y.z-1_<kernel version>.x86_64.rpm spl-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-05 20:08:07 +03:00
m4_ifvaln([$1], [SPL_LINUX_CONFTEST([$1])])
Fake modpost stage for LINUX_COMPILE. Currently, when building a test case, we're compiling an entire Linux module from beginning to end. This includes the MODPOST stage, which generates a "conftest.mod.c" file with some boilerplate module declaration code. This poses a problem when configuring for built-in on kernels which have loadable module support disabled. In this case conftest.mod.c is referencing disabled code, resulting in a compilation failure, thus breaking the tests. This patch fixes the issue by faking the modpost stage when the --enable-linux-builtin option is provided. It does so by forcing the modpost command to be /bin/true, and using an empty conftest.mod.c file. The test module still compiles fine, although the result isn't loadable, but we don't really care at this point. Note it is important to preserve the modpost stage when building out of tree. This allows for the posibility of configure checks to leverage this phase to identify GPL-only symbols. Signed-off-by: Prakash Surya <surya1@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 11:29:05 +04:00
rm -Rf build && mkdir -p build && touch build/conftest.mod.c
Build system and packaging (RPM support) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild spl-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all spl modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the spl. spl-x.y.z-1_<kernel version>.x86_64.rpm spl-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-05 20:08:07 +03:00
echo "obj-m := conftest.o" >build/Makefile
Fake modpost stage for LINUX_COMPILE. Currently, when building a test case, we're compiling an entire Linux module from beginning to end. This includes the MODPOST stage, which generates a "conftest.mod.c" file with some boilerplate module declaration code. This poses a problem when configuring for built-in on kernels which have loadable module support disabled. In this case conftest.mod.c is referencing disabled code, resulting in a compilation failure, thus breaking the tests. This patch fixes the issue by faking the modpost stage when the --enable-linux-builtin option is provided. It does so by forcing the modpost command to be /bin/true, and using an empty conftest.mod.c file. The test module still compiles fine, although the result isn't loadable, but we don't really care at this point. Note it is important to preserve the modpost stage when building out of tree. This allows for the posibility of configure checks to leverage this phase to identify GPL-only symbols. Signed-off-by: Prakash Surya <surya1@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 11:29:05 +04:00
modpost_flag=''
test "x$enable_linux_builtin" = xyes && modpost_flag='modpost=true' # fake modpost stage
Build system and packaging (RPM support) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild spl-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all spl modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the spl. spl-x.y.z-1_<kernel version>.x86_64.rpm spl-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-05 20:08:07 +03:00
AS_IF(
Fake modpost stage for LINUX_COMPILE. Currently, when building a test case, we're compiling an entire Linux module from beginning to end. This includes the MODPOST stage, which generates a "conftest.mod.c" file with some boilerplate module declaration code. This poses a problem when configuring for built-in on kernels which have loadable module support disabled. In this case conftest.mod.c is referencing disabled code, resulting in a compilation failure, thus breaking the tests. This patch fixes the issue by faking the modpost stage when the --enable-linux-builtin option is provided. It does so by forcing the modpost command to be /bin/true, and using an empty conftest.mod.c file. The test module still compiles fine, although the result isn't loadable, but we don't really care at this point. Note it is important to preserve the modpost stage when building out of tree. This allows for the posibility of configure checks to leverage this phase to identify GPL-only symbols. Signed-off-by: Prakash Surya <surya1@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 11:29:05 +04:00
[AC_TRY_COMMAND(cp conftest.c build && make [$2] -C $LINUX_OBJ EXTRA_CFLAGS="-Werror-implicit-function-declaration $EXTRA_KCFLAGS" $ARCH_UM M=$PWD/build $modpost_flag) >/dev/null && AC_TRY_COMMAND([$3])],
[$4],
[_AC_MSG_LOG_CONFTEST m4_ifvaln([$5],[$5])]
Build system and packaging (RPM support) An update to the build system to properly support all commonly used Makefile targets these include: make all # Build everything make install # Install everything make clean # Clean up build products make distclean # Clean up everything make dist # Create package tarball make srpm # Create package source RPM make rpm # Create package binary RPMs make tags # Create ctags and etags for everything Extra care was taken to ensure that the source RPMs are fully rebuildable against Fedora/RHEL/Chaos kernels. To build binary RPMs from the source RPM for your system simply run: rpmbuild --rebuild spl-x.y.z-1.src.rpm This will produce two binary RPMs with correct 'requires' dependencies for your kernel. One will contain all spl modules and support utilities, the other is a devel package for compiling additional kernel modules which are dependant on the spl. spl-x.y.z-1_<kernel version>.x86_64.rpm spl-devel-x.y.2-1_<kernel version>.x86_64.rpm
2009-03-05 20:08:07 +03:00
)
rm -Rf build
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
])
dnl #
dnl # SPL_LINUX_TRY_COMPILE like AC_TRY_COMPILE
dnl #
AC_DEFUN([SPL_LINUX_TRY_COMPILE],
[SPL_LINUX_COMPILE_IFELSE(
Reviewed and applied spl-00-rm-gpl-symbol-notifier_chain.patch from Ricardo which removes a dependency on the GPL-only symbol needed for a panic time notifier. This funcationality was never used and this improves our portability. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@159 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-03 22:53:23 +03:00
[AC_LANG_SOURCE([SPL_LANG_PROGRAM([[$1]], [[$2]])])],
[modules],
[test -s build/conftest.o],
[$3], [$4])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
])
dnl #
dnl # SPL_CHECK_SYMBOL_EXPORT
dnl # check symbol exported or not
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_CHECK_SYMBOL_EXPORT], [
Packaging improvements for RHEL and SLES (part 2) - Allow checking for exported symbols in both Module.symvers and Module.symvers. My stock SLES kernel ships an objects directory with Module.symvers, yet produces a Module.symvers in the local build directory.
2009-06-16 22:34:28 +04:00
grep -q -E '[[[:space:]]]$1[[[:space:]]]' \
$LINUX_OBJ/Module*.symvers 2>/dev/null
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
rc=$?
if test $rc -ne 0; then
export=0
for file in $2; do
Packaging improvements for RHEL and SLES (part 2) - Allow checking for exported symbols in both Module.symvers and Module.symvers. My stock SLES kernel ships an objects directory with Module.symvers, yet produces a Module.symvers in the local build directory.
2009-06-16 22:34:28 +04:00
grep -q -E "EXPORT_SYMBOL.*($1)" \
"$LINUX_OBJ/$file" 2>/dev/null
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
rc=$?
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
if test $rc -eq 0; then
export=1
break;
fi
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
done
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
if test $export -eq 0; then :
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
$4
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
else :
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
$3
fi
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
else :
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
$3
fi
])
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
dnl #
dnl # SPL_LINUX_TRY_COMPILE_SYMBOL
dnl # like SPL_LINUX_TRY_COMPILE, except SPL_CHECK_SYMBOL_EXPORT
dnl # is called if not compiling for builtin
dnl #
AC_DEFUN([SPL_LINUX_TRY_COMPILE_SYMBOL], [
SPL_LINUX_TRY_COMPILE([$1], [$2], [rc=0], [rc=1])
if test $rc -ne 0; then :
$6
else
if test "x$enable_linux_builtin" != xyes; then
SPL_CHECK_SYMBOL_EXPORT([$3], [$4], [rc=0], [rc=1])
fi
if test $rc -ne 0; then :
$6
else :
$5
fi
fi
])
Linux 3.1 compat, kern_path_parent() Prior to Linux 3.1 the kern_path_parent symbol was exported for use by kernel modules. As of Linux 3.1 it is now longer easily available. To handle this case the spl will now dynamically look up address of the missing symbol at module load time. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #52
2011-11-10 00:29:51 +04:00
dnl #
dnl # SPL_CHECK_SYMBOL_HEADER
dnl # check if a symbol prototype is defined in listed headers.
dnl #
AC_DEFUN([SPL_CHECK_SYMBOL_HEADER], [
AC_MSG_CHECKING([whether symbol $1 exists in header])
header=0
for file in $3; do
grep -q "$2" "$LINUX/$file" 2>/dev/null
rc=$?
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
if test $rc -eq 0; then
header=1
break;
fi
Linux 3.1 compat, kern_path_parent() Prior to Linux 3.1 the kern_path_parent symbol was exported for use by kernel modules. As of Linux 3.1 it is now longer easily available. To handle this case the spl will now dynamically look up address of the missing symbol at module load time. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #52
2011-11-10 00:29:51 +04:00
done
if test $header -eq 0; then
AC_MSG_RESULT([no])
$5
else
AC_MSG_RESULT([yes])
$4
fi
])
More 2.6.26 compat changes git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@153 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:56:40 +04:00
dnl #
dnl # SPL_CHECK_HEADER
dnl # check whether header exists and define HAVE_$2_HEADER
dnl #
AC_DEFUN([SPL_CHECK_HEADER],
[AC_MSG_CHECKING([whether header $1 exists])
SPL_LINUX_TRY_COMPILE([
Reviewed and applied spl-00-rm-gpl-symbol-notifier_chain.patch from Ricardo which removes a dependency on the GPL-only symbol needed for a panic time notifier. This funcationality was never used and this improves our portability. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@159 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-03 22:53:23 +03:00
#include <$1>
More 2.6.26 compat changes git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@153 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:56:40 +04:00
],[
return 0;
],[
AC_DEFINE(HAVE_$2_HEADER, 1, [$1 exists])
AC_MSG_RESULT(yes)
$3
],[
AC_MSG_RESULT(no)
$4
])
])
Pull in timespec, list, and type compat changes to support building against a wider range of kernels. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@152 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:20:11 +04:00
Make configure builtin-aware. This patch adds a new option to configure: --enable-linux-builtin. When this option is used, the following happens: - Compilation of kernel modules is disabled. - A failure to find UTS_RELEASE is followed by a suggestion to run "make prepare" on the kernel source tree. This patch also adds a new test which tries to compile an empty module as a basic toolchain sanity test. If it fails and the option was specified, the error is followed by a suggestion to run "make scripts" on the kernel source tree. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 18:34:43 +04:00
dnl #
dnl # Basic toolchain sanity check.
dnl #
AC_DEFUN([SPL_AC_TEST_MODULE],
[AC_MSG_CHECKING([whether modules can be built])
SPL_LINUX_TRY_COMPILE([],[],[
AC_MSG_RESULT([yes])
],[
AC_MSG_RESULT([no])
if test "x$enable_linux_builtin" != xyes; then
AC_MSG_ERROR([*** Unable to build an empty module.])
else
AC_MSG_ERROR([
*** Unable to build an empty module.
*** Please run 'make scripts' inside the kernel source tree.])
fi
])
])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
dnl #
Atomic64 compatibility for 32-bit systems without kernel support. This patch is another step towards updating the code to handle the 32-bit kernels which I have not been regularly testing. This changes do not really impact the common case I'm expected which is the latest kernel running on an x86_64 arch. Until the linux-2.6.31 kernel the x86 arch did not have support for 64-bit atomic operations. Additionally, the new atomic_compat.h support for this case was wrong because it embedded a spinlock in the atomic variable which must always and only be 64-bits total. To handle these 32-bit issues we now simply fall back to the --enable-atomic-spinlock implementation if the kernel does not provide the 64-bit atomic funcs. The second issue this patch addresses is the DEBUG_KMEM assumption that there will always be atomic64 funcs available. On 32-bit archs this may not be true, and actually that's just fine. In that case the kernel will will never be able to allocate more the 32-bits worth anyway. So just check if atomic64 funcs are available, if they are not it means this is a 32-bit machine and we can safely use atomic_t's instead.
2009-12-05 02:54:12 +03:00
dnl # Use the atomic implemenation based on global spinlocks. This
dnl # should only be needed by 32-bit kernels which do not provide
dnl # the atomic64_* API. It may be optionally enabled as a fallback
dnl # if problems are observed with the direct mapping to the native
dnl # Linux atomic operations. You may not disable atomic spinlocks
dnl # if you kernel does not an atomic64_* API.
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
dnl #
Atomic64 compatibility for 32-bit systems without kernel support. This patch is another step towards updating the code to handle the 32-bit kernels which I have not been regularly testing. This changes do not really impact the common case I'm expected which is the latest kernel running on an x86_64 arch. Until the linux-2.6.31 kernel the x86 arch did not have support for 64-bit atomic operations. Additionally, the new atomic_compat.h support for this case was wrong because it embedded a spinlock in the atomic variable which must always and only be 64-bits total. To handle these 32-bit issues we now simply fall back to the --enable-atomic-spinlock implementation if the kernel does not provide the 64-bit atomic funcs. The second issue this patch addresses is the DEBUG_KMEM assumption that there will always be atomic64 funcs available. On 32-bit archs this may not be true, and actually that's just fine. In that case the kernel will will never be able to allocate more the 32-bits worth anyway. So just check if atomic64 funcs are available, if they are not it means this is a 32-bit machine and we can safely use atomic_t's instead.
2009-12-05 02:54:12 +03:00
AC_DEFUN([SPL_AC_ATOMIC_SPINLOCK], [
AC_ARG_ENABLE([atomic-spinlocks],
[AS_HELP_STRING([--enable-atomic-spinlocks],
[Atomic types use spinlocks @<:@default=check@:>@])],
[],
[enable_atomic_spinlocks=check])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
Add a SPL_AC_TYPE_ATOMIC64_T test to configure for systems which do already supprt atomic64_t types. * spl-07-kmem-cleanup.patch This moves all the debugging code from sys/kmem.h to spl-kmem.c, because the huge macros were hard to debug and were bloating functions that allocated memory. I also fixed some other minor problems, including 32-bit fixes and a reported memory leak which was just due to using the wrong free function. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@163 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-04 00:06:04 +03:00
SPL_LINUX_TRY_COMPILE([
Fix atomic64_* autoconf checks The SPL_AC_ATOMIC_SPINLOCK, SPL_AC_TYPE_ATOMIC64_CMPXCHG, and SPL_AC_TYPE_ATOMIC64_XCHG were all directly including the 'asm/atomic.h' header. As of Linux 3.4 this header was removed which results in a build failure. The right thing to do is include 'linux/atomic.h' however we can't safely do this because it doesn't exist in 2.6.26 kernels. Therefore, we include 'linux/fs.h' which in turn includes the correct atomic header regardless of the kernel version. When these incorrect APIs are used in ZFS the following build failure results. arc.c:791:80: warning: '__ret' may be used uninitialized in this function [-Wuninitialized] arc.c:791:1875: error: call to '__cmpxchg_wrong_size' declared with attribute error: Bad argument size for cmpxchg Since this is all Linux 2.6.24 compatibility code there's an argument to be made that it should be removed because kernels this old are not supported. However, because we're so close to a release I'm going to leave it in place for now. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#814 Closes zfsonlinux/zfs#1254
2013-02-05 21:35:43 +04:00
#include <linux/fs.h>
Add a SPL_AC_TYPE_ATOMIC64_T test to configure for systems which do already supprt atomic64_t types. * spl-07-kmem-cleanup.patch This moves all the debugging code from sys/kmem.h to spl-kmem.c, because the huge macros were hard to debug and were bloating functions that allocated memory. I also fixed some other minor problems, including 32-bit fixes and a reported memory leak which was just due to using the wrong free function. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@163 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-04 00:06:04 +03:00
],[
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.
2011-04-19 20:26:48 +04:00
atomic64_t *ptr __attribute__ ((unused));
Add a SPL_AC_TYPE_ATOMIC64_T test to configure for systems which do already supprt atomic64_t types. * spl-07-kmem-cleanup.patch This moves all the debugging code from sys/kmem.h to spl-kmem.c, because the huge macros were hard to debug and were bloating functions that allocated memory. I also fixed some other minor problems, including 32-bit fixes and a reported memory leak which was just due to using the wrong free function. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@163 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-04 00:06:04 +03:00
],[
Atomic64 compatibility for 32-bit systems without kernel support. This patch is another step towards updating the code to handle the 32-bit kernels which I have not been regularly testing. This changes do not really impact the common case I'm expected which is the latest kernel running on an x86_64 arch. Until the linux-2.6.31 kernel the x86 arch did not have support for 64-bit atomic operations. Additionally, the new atomic_compat.h support for this case was wrong because it embedded a spinlock in the atomic variable which must always and only be 64-bits total. To handle these 32-bit issues we now simply fall back to the --enable-atomic-spinlock implementation if the kernel does not provide the 64-bit atomic funcs. The second issue this patch addresses is the DEBUG_KMEM assumption that there will always be atomic64 funcs available. On 32-bit archs this may not be true, and actually that's just fine. In that case the kernel will will never be able to allocate more the 32-bits worth anyway. So just check if atomic64 funcs are available, if they are not it means this is a 32-bit machine and we can safely use atomic_t's instead.
2009-12-05 02:54:12 +03:00
have_atomic64_t=yes
Add a SPL_AC_TYPE_ATOMIC64_T test to configure for systems which do already supprt atomic64_t types. * spl-07-kmem-cleanup.patch This moves all the debugging code from sys/kmem.h to spl-kmem.c, because the huge macros were hard to debug and were bloating functions that allocated memory. I also fixed some other minor problems, including 32-bit fixes and a reported memory leak which was just due to using the wrong free function. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@163 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-04 00:06:04 +03:00
AC_DEFINE(HAVE_ATOMIC64_T, 1,
Atomic64 compatibility for 32-bit systems without kernel support. This patch is another step towards updating the code to handle the 32-bit kernels which I have not been regularly testing. This changes do not really impact the common case I'm expected which is the latest kernel running on an x86_64 arch. Until the linux-2.6.31 kernel the x86 arch did not have support for 64-bit atomic operations. Additionally, the new atomic_compat.h support for this case was wrong because it embedded a spinlock in the atomic variable which must always and only be 64-bits total. To handle these 32-bit issues we now simply fall back to the --enable-atomic-spinlock implementation if the kernel does not provide the 64-bit atomic funcs. The second issue this patch addresses is the DEBUG_KMEM assumption that there will always be atomic64 funcs available. On 32-bit archs this may not be true, and actually that's just fine. In that case the kernel will will never be able to allocate more the 32-bits worth anyway. So just check if atomic64 funcs are available, if they are not it means this is a 32-bit machine and we can safely use atomic_t's instead.
2009-12-05 02:54:12 +03:00
[kernel defines atomic64_t])
Add a SPL_AC_TYPE_ATOMIC64_T test to configure for systems which do already supprt atomic64_t types. * spl-07-kmem-cleanup.patch This moves all the debugging code from sys/kmem.h to spl-kmem.c, because the huge macros were hard to debug and were bloating functions that allocated memory. I also fixed some other minor problems, including 32-bit fixes and a reported memory leak which was just due to using the wrong free function. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@163 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-04 00:06:04 +03:00
],[
Atomic64 compatibility for 32-bit systems without kernel support. This patch is another step towards updating the code to handle the 32-bit kernels which I have not been regularly testing. This changes do not really impact the common case I'm expected which is the latest kernel running on an x86_64 arch. Until the linux-2.6.31 kernel the x86 arch did not have support for 64-bit atomic operations. Additionally, the new atomic_compat.h support for this case was wrong because it embedded a spinlock in the atomic variable which must always and only be 64-bits total. To handle these 32-bit issues we now simply fall back to the --enable-atomic-spinlock implementation if the kernel does not provide the 64-bit atomic funcs. The second issue this patch addresses is the DEBUG_KMEM assumption that there will always be atomic64 funcs available. On 32-bit archs this may not be true, and actually that's just fine. In that case the kernel will will never be able to allocate more the 32-bits worth anyway. So just check if atomic64 funcs are available, if they are not it means this is a 32-bit machine and we can safely use atomic_t's instead.
2009-12-05 02:54:12 +03:00
have_atomic64_t=no
])
AS_IF([test "x$enable_atomic_spinlocks" = xcheck], [
AS_IF([test "x$have_atomic64_t" = xyes], [
enable_atomic_spinlocks=no
],[
enable_atomic_spinlocks=yes
])
Add a SPL_AC_TYPE_ATOMIC64_T test to configure for systems which do already supprt atomic64_t types. * spl-07-kmem-cleanup.patch This moves all the debugging code from sys/kmem.h to spl-kmem.c, because the huge macros were hard to debug and were bloating functions that allocated memory. I also fixed some other minor problems, including 32-bit fixes and a reported memory leak which was just due to using the wrong free function. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@163 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-04 00:06:04 +03:00
])
Atomic64 compatibility for 32-bit systems without kernel support. This patch is another step towards updating the code to handle the 32-bit kernels which I have not been regularly testing. This changes do not really impact the common case I'm expected which is the latest kernel running on an x86_64 arch. Until the linux-2.6.31 kernel the x86 arch did not have support for 64-bit atomic operations. Additionally, the new atomic_compat.h support for this case was wrong because it embedded a spinlock in the atomic variable which must always and only be 64-bits total. To handle these 32-bit issues we now simply fall back to the --enable-atomic-spinlock implementation if the kernel does not provide the 64-bit atomic funcs. The second issue this patch addresses is the DEBUG_KMEM assumption that there will always be atomic64 funcs available. On 32-bit archs this may not be true, and actually that's just fine. In that case the kernel will will never be able to allocate more the 32-bits worth anyway. So just check if atomic64 funcs are available, if they are not it means this is a 32-bit machine and we can safely use atomic_t's instead.
2009-12-05 02:54:12 +03:00
AS_IF([test "x$enable_atomic_spinlocks" = xyes], [
AC_DEFINE([ATOMIC_SPINLOCK], [1],
[Atomic types use spinlocks])
],[
AS_IF([test "x$have_atomic64_t" = xno], [
AC_MSG_FAILURE(
[--disable-atomic-spinlocks given but required atomic64 support is unavailable])
])
])
AC_MSG_CHECKING([whether atomic types use spinlocks])
AC_MSG_RESULT([$enable_atomic_spinlocks])
AC_MSG_CHECKING([whether kernel defines atomic64_t])
AC_MSG_RESULT([$have_atomic64_t])
Add a SPL_AC_TYPE_ATOMIC64_T test to configure for systems which do already supprt atomic64_t types. * spl-07-kmem-cleanup.patch This moves all the debugging code from sys/kmem.h to spl-kmem.c, because the huge macros were hard to debug and were bloating functions that allocated memory. I also fixed some other minor problems, including 32-bit fixes and a reported memory leak which was just due to using the wrong free function. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@163 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-04 00:06:04 +03:00
])
Add autoconf checks for atomic64_cmpxchg + atomic64_xchg These functions didn't exist for all archs prior to 2.6.24. This patch addes an autoconf test to detect this and add them when needed. The autoconf check is needed instead of just an #ifndef because in the most modern kernels atomic64_{cmp}xchg are implemented as in inline function and not a #define.
2009-10-30 23:53:17 +03:00
dnl #
dnl # 2.6.24 API change,
dnl # check if atomic64_cmpxchg is defined
dnl #
AC_DEFUN([SPL_AC_TYPE_ATOMIC64_CMPXCHG],
[AC_MSG_CHECKING([whether kernel defines atomic64_cmpxchg])
SPL_LINUX_TRY_COMPILE([
Fix atomic64_* autoconf checks The SPL_AC_ATOMIC_SPINLOCK, SPL_AC_TYPE_ATOMIC64_CMPXCHG, and SPL_AC_TYPE_ATOMIC64_XCHG were all directly including the 'asm/atomic.h' header. As of Linux 3.4 this header was removed which results in a build failure. The right thing to do is include 'linux/atomic.h' however we can't safely do this because it doesn't exist in 2.6.26 kernels. Therefore, we include 'linux/fs.h' which in turn includes the correct atomic header regardless of the kernel version. When these incorrect APIs are used in ZFS the following build failure results. arc.c:791:80: warning: '__ret' may be used uninitialized in this function [-Wuninitialized] arc.c:791:1875: error: call to '__cmpxchg_wrong_size' declared with attribute error: Bad argument size for cmpxchg Since this is all Linux 2.6.24 compatibility code there's an argument to be made that it should be removed because kernels this old are not supported. However, because we're so close to a release I'm going to leave it in place for now. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#814 Closes zfsonlinux/zfs#1254
2013-02-05 21:35:43 +04:00
#include <linux/fs.h>
Add autoconf checks for atomic64_cmpxchg + atomic64_xchg These functions didn't exist for all archs prior to 2.6.24. This patch addes an autoconf test to detect this and add them when needed. The autoconf check is needed instead of just an #ifndef because in the most modern kernels atomic64_{cmp}xchg are implemented as in inline function and not a #define.
2009-10-30 23:53:17 +03:00
],[
atomic64_cmpxchg((atomic64_t *)NULL, 0, 0);
],[
AC_MSG_RESULT([yes])
AC_DEFINE(HAVE_ATOMIC64_CMPXCHG, 1,
[kernel defines atomic64_cmpxchg])
],[
AC_MSG_RESULT([no])
])
])
dnl #
dnl # 2.6.24 API change,
dnl # check if atomic64_xchg is defined
dnl #
AC_DEFUN([SPL_AC_TYPE_ATOMIC64_XCHG],
[AC_MSG_CHECKING([whether kernel defines atomic64_xchg])
SPL_LINUX_TRY_COMPILE([
Fix atomic64_* autoconf checks The SPL_AC_ATOMIC_SPINLOCK, SPL_AC_TYPE_ATOMIC64_CMPXCHG, and SPL_AC_TYPE_ATOMIC64_XCHG were all directly including the 'asm/atomic.h' header. As of Linux 3.4 this header was removed which results in a build failure. The right thing to do is include 'linux/atomic.h' however we can't safely do this because it doesn't exist in 2.6.26 kernels. Therefore, we include 'linux/fs.h' which in turn includes the correct atomic header regardless of the kernel version. When these incorrect APIs are used in ZFS the following build failure results. arc.c:791:80: warning: '__ret' may be used uninitialized in this function [-Wuninitialized] arc.c:791:1875: error: call to '__cmpxchg_wrong_size' declared with attribute error: Bad argument size for cmpxchg Since this is all Linux 2.6.24 compatibility code there's an argument to be made that it should be removed because kernels this old are not supported. However, because we're so close to a release I'm going to leave it in place for now. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#814 Closes zfsonlinux/zfs#1254
2013-02-05 21:35:43 +04:00
#include <linux/fs.h>
Add autoconf checks for atomic64_cmpxchg + atomic64_xchg These functions didn't exist for all archs prior to 2.6.24. This patch addes an autoconf test to detect this and add them when needed. The autoconf check is needed instead of just an #ifndef because in the most modern kernels atomic64_{cmp}xchg are implemented as in inline function and not a #define.
2009-10-30 23:53:17 +03:00
],[
atomic64_xchg((atomic64_t *)NULL, 0);
],[
AC_MSG_RESULT([yes])
AC_DEFINE(HAVE_ATOMIC64_XCHG, 1,
[kernel defines atomic64_xchg])
],[
AC_MSG_RESULT([no])
])
])
Atomic64 compatibility for 32-bit systems without kernel support. This patch is another step towards updating the code to handle the 32-bit kernels which I have not been regularly testing. This changes do not really impact the common case I'm expected which is the latest kernel running on an x86_64 arch. Until the linux-2.6.31 kernel the x86 arch did not have support for 64-bit atomic operations. Additionally, the new atomic_compat.h support for this case was wrong because it embedded a spinlock in the atomic variable which must always and only be 64-bits total. To handle these 32-bit issues we now simply fall back to the --enable-atomic-spinlock implementation if the kernel does not provide the 64-bit atomic funcs. The second issue this patch addresses is the DEBUG_KMEM assumption that there will always be atomic64 funcs available. On 32-bit archs this may not be true, and actually that's just fine. In that case the kernel will will never be able to allocate more the 32-bits worth anyway. So just check if atomic64 funcs are available, if they are not it means this is a 32-bit machine and we can safely use atomic_t's instead.
2009-12-05 02:54:12 +03:00
dnl #
dnl # 2.6.24 API change,
dnl # check if uintptr_t typedef is defined
dnl #
AC_DEFUN([SPL_AC_TYPE_UINTPTR_T],
[AC_MSG_CHECKING([whether kernel defines uintptr_t])
SPL_LINUX_TRY_COMPILE([
#include <linux/types.h>
],[
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.
2011-04-19 20:26:48 +04:00
uintptr_t *ptr __attribute__ ((unused));
Atomic64 compatibility for 32-bit systems without kernel support. This patch is another step towards updating the code to handle the 32-bit kernels which I have not been regularly testing. This changes do not really impact the common case I'm expected which is the latest kernel running on an x86_64 arch. Until the linux-2.6.31 kernel the x86 arch did not have support for 64-bit atomic operations. Additionally, the new atomic_compat.h support for this case was wrong because it embedded a spinlock in the atomic variable which must always and only be 64-bits total. To handle these 32-bit issues we now simply fall back to the --enable-atomic-spinlock implementation if the kernel does not provide the 64-bit atomic funcs. The second issue this patch addresses is the DEBUG_KMEM assumption that there will always be atomic64 funcs available. On 32-bit archs this may not be true, and actually that's just fine. In that case the kernel will will never be able to allocate more the 32-bits worth anyway. So just check if atomic64 funcs are available, if they are not it means this is a 32-bit machine and we can safely use atomic_t's instead.
2009-12-05 02:54:12 +03:00
],[
AC_MSG_RESULT([yes])
AC_DEFINE(HAVE_UINTPTR_T, 1,
[kernel defines uintptr_t])
],[
AC_MSG_RESULT([no])
])
])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
dnl #
Commit bulk of remaining 2.6.9 and 2.6.26 compat changes. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@155 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-12 02:13:47 +04:00
dnl # 2.6.21 API change,
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
dnl # 'register_sysctl_table' use only one argument instead of two
dnl #
AC_DEFUN([SPL_AC_2ARGS_REGISTER_SYSCTL],
[AC_MSG_CHECKING([whether register_sysctl_table() wants 2 args])
SPL_LINUX_TRY_COMPILE([
Reviewed and applied spl-00-rm-gpl-symbol-notifier_chain.patch from Ricardo which removes a dependency on the GPL-only symbol needed for a panic time notifier. This funcationality was never used and this improves our portability. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@159 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-03 22:53:23 +03:00
#include <linux/sysctl.h>
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
],[
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.
2011-04-19 20:26:48 +04:00
(void) register_sysctl_table(NULL, 0);
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
],[
Reviewed and applied spl-00-rm-gpl-symbol-notifier_chain.patch from Ricardo which removes a dependency on the GPL-only symbol needed for a panic time notifier. This funcationality was never used and this improves our portability. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@159 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-03 22:53:23 +03:00
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_2ARGS_REGISTER_SYSCTL, 1,
[register_sysctl_table() wants 2 args])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
],[
Reviewed and applied spl-00-rm-gpl-symbol-notifier_chain.patch from Ricardo which removes a dependency on the GPL-only symbol needed for a panic time notifier. This funcationality was never used and this improves our portability. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@159 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-03 22:53:23 +03:00
AC_MSG_RESULT(no)
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
])
])
Linux 3.12 compat: New shrinker API torvalds/linux@24f7c6 introduced a new shrinker API while torvalds/linux@a0b021 dropped support for the old shrinker API. This patch adds support for the new shrinker API by wrapping the old one with the new one. This change also reorganizes the autotools checks on the shrinker API such that the configure script will fail early if an unknown API is encountered in the future. Support for the set_shrinker() API which was used by Linux 2.6.22 and older has been dropped. As a general rule compatibility is only maintained back to Linux 2.6.26. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#1732 Closes zfsonlinux/zfs#1822 Closes #293 Closes #307
2013-11-05 20:35:54 +04:00
AC_DEFUN([SPL_AC_SHRINKER_CALLBACK],[
Fix 2.6.35 shrinker callback API change As of linux-2.6.35 the shrinker callback API now takes an additional argument. The shrinker struct is passed to the callback so that users can embed the shrinker structure in private data and use container_of() to access it. This removes the need to always use global state for the shrinker. To handle this we add the SPL_AC_3ARGS_SHRINKER_CALLBACK autoconf check to properly detect the API. Then we simply setup a callback function with the correct number of arguments. For now we do not make use of the new 3rd argument.
2010-10-23 01:16:43 +04:00
tmp_flags="$EXTRA_KCFLAGS"
EXTRA_KCFLAGS="-Werror"
Linux 3.12 compat: New shrinker API torvalds/linux@24f7c6 introduced a new shrinker API while torvalds/linux@a0b021 dropped support for the old shrinker API. This patch adds support for the new shrinker API by wrapping the old one with the new one. This change also reorganizes the autotools checks on the shrinker API such that the configure script will fail early if an unknown API is encountered in the future. Support for the set_shrinker() API which was used by Linux 2.6.22 and older has been dropped. As a general rule compatibility is only maintained back to Linux 2.6.26. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#1732 Closes zfsonlinux/zfs#1822 Closes #293 Closes #307
2013-11-05 20:35:54 +04:00
dnl #
dnl # 2.6.23 to 2.6.34 API change
dnl # ->shrink(int nr_to_scan, gfp_t gfp_mask)
dnl #
AC_MSG_CHECKING([whether old 2-argument shrinker exists])
Fix 2.6.35 shrinker callback API change As of linux-2.6.35 the shrinker callback API now takes an additional argument. The shrinker struct is passed to the callback so that users can embed the shrinker structure in private data and use container_of() to access it. This removes the need to always use global state for the shrinker. To handle this we add the SPL_AC_3ARGS_SHRINKER_CALLBACK autoconf check to properly detect the API. Then we simply setup a callback function with the correct number of arguments. For now we do not make use of the new 3rd argument.
2010-10-23 01:16:43 +04:00
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
Linux 3.12 compat: New shrinker API torvalds/linux@24f7c6 introduced a new shrinker API while torvalds/linux@a0b021 dropped support for the old shrinker API. This patch adds support for the new shrinker API by wrapping the old one with the new one. This change also reorganizes the autotools checks on the shrinker API such that the configure script will fail early if an unknown API is encountered in the future. Support for the set_shrinker() API which was used by Linux 2.6.22 and older has been dropped. As a general rule compatibility is only maintained back to Linux 2.6.26. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#1732 Closes zfsonlinux/zfs#1822 Closes #293 Closes #307
2013-11-05 20:35:54 +04:00
int shrinker_cb(int nr_to_scan, gfp_t gfp_mask);
Fix 2.6.35 shrinker callback API change As of linux-2.6.35 the shrinker callback API now takes an additional argument. The shrinker struct is passed to the callback so that users can embed the shrinker structure in private data and use container_of() to access it. This removes the need to always use global state for the shrinker. To handle this we add the SPL_AC_3ARGS_SHRINKER_CALLBACK autoconf check to properly detect the API. Then we simply setup a callback function with the correct number of arguments. For now we do not make use of the new 3rd argument.
2010-10-23 01:16:43 +04:00
],[
struct shrinker cache_shrinker = {
.shrink = shrinker_cb,
.seeks = DEFAULT_SEEKS,
};
register_shrinker(&cache_shrinker);
],[
AC_MSG_RESULT(yes)
Linux 3.12 compat: New shrinker API torvalds/linux@24f7c6 introduced a new shrinker API while torvalds/linux@a0b021 dropped support for the old shrinker API. This patch adds support for the new shrinker API by wrapping the old one with the new one. This change also reorganizes the autotools checks on the shrinker API such that the configure script will fail early if an unknown API is encountered in the future. Support for the set_shrinker() API which was used by Linux 2.6.22 and older has been dropped. As a general rule compatibility is only maintained back to Linux 2.6.26. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#1732 Closes zfsonlinux/zfs#1822 Closes #293 Closes #307
2013-11-05 20:35:54 +04:00
AC_DEFINE(HAVE_2ARGS_OLD_SHRINKER_CALLBACK, 1,
[old shrinker callback wants 2 args])
Fix 2.6.35 shrinker callback API change As of linux-2.6.35 the shrinker callback API now takes an additional argument. The shrinker struct is passed to the callback so that users can embed the shrinker structure in private data and use container_of() to access it. This removes the need to always use global state for the shrinker. To handle this we add the SPL_AC_3ARGS_SHRINKER_CALLBACK autoconf check to properly detect the API. Then we simply setup a callback function with the correct number of arguments. For now we do not make use of the new 3rd argument.
2010-10-23 01:16:43 +04:00
],[
AC_MSG_RESULT(no)
Linux 3.12 compat: New shrinker API torvalds/linux@24f7c6 introduced a new shrinker API while torvalds/linux@a0b021 dropped support for the old shrinker API. This patch adds support for the new shrinker API by wrapping the old one with the new one. This change also reorganizes the autotools checks on the shrinker API such that the configure script will fail early if an unknown API is encountered in the future. Support for the set_shrinker() API which was used by Linux 2.6.22 and older has been dropped. As a general rule compatibility is only maintained back to Linux 2.6.26. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#1732 Closes zfsonlinux/zfs#1822 Closes #293 Closes #307
2013-11-05 20:35:54 +04:00
dnl #
dnl # 2.6.35 - 2.6.39 API change
dnl # ->shrink(struct shrinker *,
dnl # int nr_to_scan, gfp_t gfp_mask)
dnl #
AC_MSG_CHECKING([whether old 3-argument shrinker exists])
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
int shrinker_cb(struct shrinker *, int nr_to_scan,
gfp_t gfp_mask);
],[
struct shrinker cache_shrinker = {
.shrink = shrinker_cb,
.seeks = DEFAULT_SEEKS,
};
register_shrinker(&cache_shrinker);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_3ARGS_SHRINKER_CALLBACK, 1,
[old shrinker callback wants 3 args])
],[
AC_MSG_RESULT(no)
dnl #
dnl # 3.0 - 3.11 API change
dnl # ->shrink(struct shrinker *,
dnl # struct shrink_control *sc)
dnl #
AC_MSG_CHECKING(
[whether new 2-argument shrinker exists])
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
int shrinker_cb(struct shrinker *,
struct shrink_control *sc);
],[
struct shrinker cache_shrinker = {
.shrink = shrinker_cb,
.seeks = DEFAULT_SEEKS,
};
register_shrinker(&cache_shrinker);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_2ARGS_NEW_SHRINKER_CALLBACK, 1,
[new shrinker callback wants 2 args])
],[
AC_MSG_RESULT(no)
dnl #
dnl # 3.12 API change,
dnl # ->shrink() is logically split in to
dnl # ->count_objects() and ->scan_objects()
dnl #
AC_MSG_CHECKING(
[whether ->count_objects callback exists])
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
unsigned long shrinker_cb(
struct shrinker *,
struct shrink_control *sc);
],[
struct shrinker cache_shrinker = {
.count_objects = shrinker_cb,
.scan_objects = shrinker_cb,
.seeks = DEFAULT_SEEKS,
};
register_shrinker(&cache_shrinker);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_SPLIT_SHRINKER_CALLBACK,
1, [->count_objects exists])
],[
AC_MSG_ERROR(error)
])
])
])
Fix 2.6.35 shrinker callback API change As of linux-2.6.35 the shrinker callback API now takes an additional argument. The shrinker struct is passed to the callback so that users can embed the shrinker structure in private data and use container_of() to access it. This removes the need to always use global state for the shrinker. To handle this we add the SPL_AC_3ARGS_SHRINKER_CALLBACK autoconf check to properly detect the API. Then we simply setup a callback function with the correct number of arguments. For now we do not make use of the new 3rd argument.
2010-10-23 01:16:43 +04:00
])
EXTRA_KCFLAGS="$tmp_flags"
])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
dnl #
dnl # Custom SPL patch may export this system it is not required
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_TASK_CURR],
[AC_MSG_CHECKING([whether task_curr() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/sched.h>
], [
task_curr(NULL);
], [task_curr], [kernel/sched.c], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_TASK_CURR, 1, [task_curr() is available])
], [
AC_MSG_RESULT(no)
])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
])
dnl #
Commit bulk of remaining 2.6.9 and 2.6.26 compat changes. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@155 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-12 02:13:47 +04:00
dnl # 2.6.19 API change,
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
dnl # Use CTL_UNNUMBERED when binary sysctl is not required
dnl #
AC_DEFUN([SPL_AC_CTL_UNNUMBERED],
[AC_MSG_CHECKING([whether unnumbered sysctl support exists])
SPL_LINUX_TRY_COMPILE([
Reviewed and applied spl-00-rm-gpl-symbol-notifier_chain.patch from Ricardo which removes a dependency on the GPL-only symbol needed for a panic time notifier. This funcationality was never used and this improves our portability. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@159 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-03 22:53:23 +03:00
#include <linux/sysctl.h>
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
],[
#ifndef CTL_UNNUMBERED
#error CTL_UNNUMBERED undefined
#endif
],[
Reviewed and applied spl-00-rm-gpl-symbol-notifier_chain.patch from Ricardo which removes a dependency on the GPL-only symbol needed for a panic time notifier. This funcationality was never used and this improves our portability. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@159 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-03 22:53:23 +03:00
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_CTL_UNNUMBERED, 1,
[unnumbered sysctl support exists])
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
],[
Reviewed and applied spl-00-rm-gpl-symbol-notifier_chain.patch from Ricardo which removes a dependency on the GPL-only symbol needed for a panic time notifier. This funcationality was never used and this improves our portability. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@159 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-11-03 22:53:23 +03:00
AC_MSG_RESULT(no)
Breaking the world for a little bit. If anyone is going to continue working on this branch for the next few days I suggested you work off of the 0.3.1 tag. The following changes are fairly extensive and are designed to make the SPL compatible with all kernels in the range of 2.6.18-2.6.25. There were 13 relevant API changes between these releases and I have added the needed autoconf tests to check for them. However, this has not all been tested extensively. I'll sort of the breakage on Fedora Core 9 and RHEL5 this week. SPL_AC_TYPE_UINTPTR_T SPL_AC_TYPE_KMEM_CACHE_T SPL_AC_KMEM_CACHE_DESTROY_INT SPL_AC_ATOMIC_PANIC_NOTIFIER SPL_AC_3ARGS_INIT_WORK SPL_AC_2ARGS_REGISTER_SYSCTL SPL_AC_KMEM_CACHE_T SPL_AC_KMEM_CACHE_CREATE_DTOR SPL_AC_3ARG_KMEM_CACHE_CREATE_CTOR SPL_AC_SET_SHRINKER SPL_AC_PATH_IN_NAMEIDATA SPL_AC_TASK_CURR SPL_AC_CTL_UNNUMBERED git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@119 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-06-02 21:28:49 +04:00
])
])
Pull in fls64 compat changes from spl-00-rhel4-compat.patch, to allow greater compatibility with kernels pre 2.6.16. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@149 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-06 08:52:39 +04:00
Linux-2.6.33 compat, .ctl_name removed from struct ctl_table As of linux-2.6.33 the ctl_name member of the ctl_table struct has been entirely removed. The upstream code has been updated to depend entirely on the the procname member. To handle this all references to ctl_name are wrapped in a CTL_NAME macro which simply expands to nothing for newer kernels. Older kernels are supported by having it expand to .ctl_name = X just as before.
2010-06-30 21:36:20 +04:00
dnl #
dnl # 2.6.33 API change,
dnl # Removed .ctl_name from struct ctl_table.
dnl #
AC_DEFUN([SPL_AC_CTL_NAME], [
AC_MSG_CHECKING([whether struct ctl_table has ctl_name])
SPL_LINUX_TRY_COMPILE([
#include <linux/sysctl.h>
],[
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.
2011-04-19 20:26:48 +04:00
struct ctl_table ctl __attribute__ ((unused));
Linux-2.6.33 compat, .ctl_name removed from struct ctl_table As of linux-2.6.33 the ctl_name member of the ctl_table struct has been entirely removed. The upstream code has been updated to depend entirely on the the procname member. To handle this all references to ctl_name are wrapped in a CTL_NAME macro which simply expands to nothing for newer kernels. Older kernels are supported by having it expand to .ctl_name = X just as before.
2010-06-30 21:36:20 +04:00
ctl.ctl_name = 0;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_CTL_NAME, 1, [struct ctl_table has ctl_name])
],[
AC_MSG_RESULT(no)
])
])
Pull in fls64 compat changes from spl-00-rhel4-compat.patch, to allow greater compatibility with kernels pre 2.6.16. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@149 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-06 08:52:39 +04:00
dnl #
dnl # 2.6.16 API change.
dnl # Check if 'fls64()' is available
dnl #
AC_DEFUN([SPL_AC_FLS64],
Pull in timespec, list, and type compat changes to support building against a wider range of kernels. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@152 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:20:11 +04:00
[AC_MSG_CHECKING([whether fls64() is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/bitops.h>
],[
return fls64(0);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_FLS64, 1, [fls64() is available])
],[
AC_MSG_RESULT(no)
])
Pull in fls64 compat changes from spl-00-rhel4-compat.patch, to allow greater compatibility with kernels pre 2.6.16. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@149 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-06 08:52:39 +04:00
])
Add class / device portability code. Two autoconf tests were added to cover the 3 possible APIs from 2.6.9 to 2.6.26. We attempt to use the newest interfaces and if not available fallback to the oldest. This a rework of some changes proposed by Ricardo for RHEL4. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@150 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-10 07:50:36 +04:00
dnl #
dnl # 2.6.18 API change, check whether device_create() is available.
dnl # Device_create() was introduced in 2.6.18 and depricated
dnl # class_device_create() which was fully removed in 2.6.26.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_DEVICE_CREATE],
[AC_MSG_CHECKING([whether device_create() is available])
SPL_CHECK_SYMBOL_EXPORT([device_create], [drivers/base/core.c], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_DEVICE_CREATE, 1,
[device_create() is available])
], [
AC_MSG_RESULT(no)
])
Add class / device portability code. Two autoconf tests were added to cover the 3 possible APIs from 2.6.9 to 2.6.26. We attempt to use the newest interfaces and if not available fallback to the oldest. This a rework of some changes proposed by Ricardo for RHEL4. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@150 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-10 07:50:36 +04:00
])
Added SPL_AC_5ARGS_DEVICE_CREATE autoconf configure check As of 2.6.27 kernels the device_create() API changed to include a private data argument. This check detects which version of device_create() function the kernel has and properly defines spl_device_create() to use the correct prototype.
2009-03-13 23:38:43 +03:00
dnl #
dnl # 2.6.27 API change,
dnl # device_create() uses 5 args, new 'drvdata' argument.
dnl #
AC_DEFUN([SPL_AC_5ARGS_DEVICE_CREATE], [
AC_MSG_CHECKING([whether device_create() wants 5 args])
tmp_flags="$EXTRA_KCFLAGS"
EXTRA_KCFLAGS="-Werror"
SPL_LINUX_TRY_COMPILE([
#include <linux/device.h>
],[
device_create(NULL, NULL, 0, NULL, "%d", 1);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_5ARGS_DEVICE_CREATE, 1,
[device_create wants 5 args])
],[
AC_MSG_RESULT(no)
])
EXTRA_KCFLAGS="$tmp_flags"
])
Add class / device portability code. Two autoconf tests were added to cover the 3 possible APIs from 2.6.9 to 2.6.26. We attempt to use the newest interfaces and if not available fallback to the oldest. This a rework of some changes proposed by Ricardo for RHEL4. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@150 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-10 07:50:36 +04:00
dnl #
dnl # 2.6.13 API change, check whether class_device_create() is available.
dnl # Class_device_create() was introduced in 2.6.13 and depricated
dnl # class_simple_device_add() which was fully removed in 2.6.13.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_CLASS_DEVICE_CREATE],
[AC_MSG_CHECKING([whether class_device_create() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/device.h>
], [
class_device_create(NULL, NULL, 0, NULL, NULL);
], [class_device_create], [drivers/base/class.c], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_CLASS_DEVICE_CREATE, 1,
[class_device_create() is available])
], [
AC_MSG_RESULT(no)
])
Add class / device portability code. Two autoconf tests were added to cover the 3 possible APIs from 2.6.9 to 2.6.26. We attempt to use the newest interfaces and if not available fallback to the oldest. This a rework of some changes proposed by Ricardo for RHEL4. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@150 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-10 07:50:36 +04:00
])
Pull in timespec, list, and type compat changes to support building against a wider range of kernels. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@152 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:20:11 +04:00
dnl #
dnl # 2.6.26 API change, set_normalized_timespec() is exported.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_SET_NORMALIZED_TIMESPEC_EXPORT],
[AC_MSG_CHECKING([whether set_normalized_timespec() is available as export])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/time.h>
], [
set_normalized_timespec(NULL, 0, 0);
], [set_normalized_timespec], [kernel/time.c], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_SET_NORMALIZED_TIMESPEC_EXPORT, 1,
[set_normalized_timespec() is available as export])
], [
AC_MSG_RESULT(no)
])
Pull in timespec, list, and type compat changes to support building against a wider range of kernels. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@152 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:20:11 +04:00
])
dnl #
dnl # 2.6.16 API change, set_normalize_timespec() moved to time.c
dnl # previously it was available in time.h as an inline.
dnl #
More 2.6.26 compat changes git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@153 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:56:40 +04:00
AC_DEFUN([SPL_AC_SET_NORMALIZED_TIMESPEC_INLINE], [
AC_MSG_CHECKING([whether set_normalized_timespec() is an inline])
Pull in timespec, list, and type compat changes to support building against a wider range of kernels. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@152 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:20:11 +04:00
SPL_LINUX_TRY_COMPILE([
#include <linux/time.h>
void set_normalized_timespec(struct timespec *ts,
Sigh more compat fixes, this is almost right for 2.6.9 - 2.6.26 kernels. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@157 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-12 03:47:44 +04:00
time_t sec, long nsec) { }
],
[],
[
Pull in timespec, list, and type compat changes to support building against a wider range of kernels. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@152 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:20:11 +04:00
AC_MSG_RESULT(no)
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_SET_NORMALIZED_TIMESPEC_INLINE, 1,
[set_normalized_timespec() is available as inline])
])
])
dnl #
dnl # 2.6.18 API change,
dnl # timespec_sub() inline function available in linux/time.h
dnl #
More 2.6.26 compat changes git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@153 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:56:40 +04:00
AC_DEFUN([SPL_AC_TIMESPEC_SUB], [
AC_MSG_CHECKING([whether timespec_sub() is available])
Pull in timespec, list, and type compat changes to support building against a wider range of kernels. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@152 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:20:11 +04:00
SPL_LINUX_TRY_COMPILE([
#include <linux/time.h>
],[
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.
2011-04-19 20:26:48 +04:00
struct timespec a = { 0 };
struct timespec b = { 0 };
struct timespec c __attribute__ ((unused));
Pull in timespec, list, and type compat changes to support building against a wider range of kernels. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@152 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:20:11 +04:00
c = timespec_sub(a, b);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_TIMESPEC_SUB, 1, [timespec_sub() is available])
],[
AC_MSG_RESULT(no)
])
])
More 2.6.26 compat changes git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@153 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 21:56:40 +04:00
dnl #
Commit bulk of remaining 2.6.9 and 2.6.26 compat changes. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@155 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-12 02:13:47 +04:00
dnl # 2.6.19 API change,
dnl # check if init_utsname() is available in linux/utsname.h
dnl #
AC_DEFUN([SPL_AC_INIT_UTSNAME], [
AC_MSG_CHECKING([whether init_utsname() is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/utsname.h>
],[
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.
2011-04-19 20:26:48 +04:00
struct new_utsname *a __attribute__ ((unused));
a = init_utsname();
Commit bulk of remaining 2.6.9 and 2.6.26 compat changes. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@155 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-12 02:13:47 +04:00
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_INIT_UTSNAME, 1, [init_utsname() is available])
],[
AC_MSG_RESULT(no)
])
])
dnl #
dnl # 2.6.18 API change,
dnl # added linux/uaccess.h
Include linux/uaccess.h compat changes. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@154 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-11 23:10:14 +04:00
dnl #
AC_DEFUN([SPL_AC_UACCESS_HEADER], [
SPL_CHECK_HEADER([linux/uaccess.h], [UACCESS], [], [])
])
Commit bulk of remaining 2.6.9 and 2.6.26 compat changes. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@155 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-12 02:13:47 +04:00
dnl #
dnl # 2.6.12 API change,
dnl # check whether 'kmalloc_node()' is available.
dnl #
AC_DEFUN([SPL_AC_KMALLOC_NODE], [
AC_MSG_CHECKING([whether kmalloc_node() is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/slab.h>
],[
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.
2011-04-19 20:26:48 +04:00
void *a __attribute__ ((unused));
a = kmalloc_node(1, GFP_KERNEL, 0);
Commit bulk of remaining 2.6.9 and 2.6.26 compat changes. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@155 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-12 02:13:47 +04:00
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_KMALLOC_NODE, 1, [kmalloc_node() is available])
],[
AC_MSG_RESULT(no)
])
])
dnl #
dnl # 2.6.9 API change,
dnl # check whether 'monotonic_clock()' is available it may
dnl # be available for some archs but not others.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_MONOTONIC_CLOCK],
[AC_MSG_CHECKING([whether monotonic_clock() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/timex.h>
], [
monotonic_clock();
], [monotonic_clock], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_MONOTONIC_CLOCK, 1,
[monotonic_clock() is available])
], [
AC_MSG_RESULT(no)
])
Commit bulk of remaining 2.6.9 and 2.6.26 compat changes. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@155 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-12 02:13:47 +04:00
])
dnl #
dnl # 2.6.16 API change,
dnl # check whether 'struct inode' has i_mutex
dnl #
AC_DEFUN([SPL_AC_INODE_I_MUTEX], [
AC_MSG_CHECKING([whether struct inode has i_mutex])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
#include <linux/mutex.h>
],[
struct inode i;
mutex_init(&i.i_mutex);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_INODE_I_MUTEX, 1, [struct inode has i_mutex])
],[
AC_MSG_RESULT(no)
])
])
Pull in initial 32-bit support patches. git-svn-id: https://outreach.scidac.gov/svn/spl/trunk@156 7e1ea52c-4ff2-0310-8f11-9dd32ca42a1c
2008-08-12 02:42:04 +04:00
Reimplement mutexs for Linux lock profiling/analysis For a generic explanation of why mutexs needed to be reimplemented to work with the kernel lock profiling see commits: e811949a57044d60d12953c5c3b808a79a7d36ef and d28db80fd0fd4fd63aec09037c44408e51a222d6 The specific changes made to the mutex implemetation are as follows. The Linux mutex structure is now directly embedded in the kmutex_t. This allows a kmutex_t to be directly case to a mutex struct and passed directly to the Linux primative. Just like with the rwlocks it is critical that these functions be implemented as '#defines to ensure the location information is preserved. The preprocessor can then do a direct replacement of the Solaris primative with the linux primative. Just as with the rwlocks we need to track the lock owner. Here things get a little more interesting because depending on your kernel version, and how you've built your kernel Linux may already do this for you. If your running a 2.6.29 or newer kernel on a SMP system the lock owner will be tracked. This was added to Linux to support adaptive mutexs, more on that shortly. Alternately, your kernel might track the lock owner if you've set CONFIG_DEBUG_MUTEXES in the kernel build. If neither of the above things is true for your kernel the kmutex_t type will include and track the lock owner to ensure correct behavior. This is all handled by a new autoconf check called SPL_AC_MUTEX_OWNER. Concerning adaptive mutexs these are a very recent development and they did not make it in to either the latest FC11 of SLES11 kernels. Ideally, I'd love to see this kernel change appear in one of these distros because it does help performance. From Linux kernel commit: 0d66bf6d3514b35eb6897629059443132992dbd7 "Testing with Ingo's test-mutex application... gave a 345% boost for VFS scalability on my testbox" However, if you don't want to backport this change yourself you can still simply export the task_curr() symbol. The kmutex_t implementation will use this symbol when it's available to provide it's own adaptive mutexs. Finally, DEBUG_MUTEX support was removed including the proc handlers. This was done because now that we are cleanly integrated with the kernel profiling all this information and much much more is available in debug kernel builds. This code was now redundant. Update mutexs validated on: - SLES10 (ppc64) - SLES11 (x86_64) - CHAOS4.2 (x86_64) - RHEL5.3 (x86_64) - RHEL6 (x86_64) - FC11 (x86_64)
2009-09-26 01:47:01 +04:00
dnl #
dnl # 2.6.29 API change,
dnl # Adaptive mutexs introduced.
dnl #
AC_DEFUN([SPL_AC_MUTEX_OWNER], [
AC_MSG_CHECKING([whether struct mutex has owner])
SPL_LINUX_TRY_COMPILE([
#include <linux/mutex.h>
],[
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.
2011-04-19 20:26:48 +04:00
struct mutex mtx __attribute__ ((unused));
Reimplement mutexs for Linux lock profiling/analysis For a generic explanation of why mutexs needed to be reimplemented to work with the kernel lock profiling see commits: e811949a57044d60d12953c5c3b808a79a7d36ef and d28db80fd0fd4fd63aec09037c44408e51a222d6 The specific changes made to the mutex implemetation are as follows. The Linux mutex structure is now directly embedded in the kmutex_t. This allows a kmutex_t to be directly case to a mutex struct and passed directly to the Linux primative. Just like with the rwlocks it is critical that these functions be implemented as '#defines to ensure the location information is preserved. The preprocessor can then do a direct replacement of the Solaris primative with the linux primative. Just as with the rwlocks we need to track the lock owner. Here things get a little more interesting because depending on your kernel version, and how you've built your kernel Linux may already do this for you. If your running a 2.6.29 or newer kernel on a SMP system the lock owner will be tracked. This was added to Linux to support adaptive mutexs, more on that shortly. Alternately, your kernel might track the lock owner if you've set CONFIG_DEBUG_MUTEXES in the kernel build. If neither of the above things is true for your kernel the kmutex_t type will include and track the lock owner to ensure correct behavior. This is all handled by a new autoconf check called SPL_AC_MUTEX_OWNER. Concerning adaptive mutexs these are a very recent development and they did not make it in to either the latest FC11 of SLES11 kernels. Ideally, I'd love to see this kernel change appear in one of these distros because it does help performance. From Linux kernel commit: 0d66bf6d3514b35eb6897629059443132992dbd7 "Testing with Ingo's test-mutex application... gave a 345% boost for VFS scalability on my testbox" However, if you don't want to backport this change yourself you can still simply export the task_curr() symbol. The kmutex_t implementation will use this symbol when it's available to provide it's own adaptive mutexs. Finally, DEBUG_MUTEX support was removed including the proc handlers. This was done because now that we are cleanly integrated with the kernel profiling all this information and much much more is available in debug kernel builds. This code was now redundant. Update mutexs validated on: - SLES10 (ppc64) - SLES11 (x86_64) - CHAOS4.2 (x86_64) - RHEL5.3 (x86_64) - RHEL6 (x86_64) - FC11 (x86_64)
2009-09-26 01:47:01 +04:00
mtx.owner = NULL;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_MUTEX_OWNER, 1, [struct mutex has owner])
],[
AC_MSG_RESULT(no)
])
])
Linux 2.6.39 compat, mutex owner Prior to Linux 2.6.39 when CONFIG_DEBUG_MUTEXES was defined the kernel stored a thread_info pointer as the mutex owner. From this you could get the pointer of the current task_struct to compare with get_current(). As of Linux 2.6.39 this behavior has changed and now the mutex stores a pointer to the task_struct. This commit detects the type of pointer stored in the mutex and adjusts the mutex_owner() and mutex_owned() functions to perform the correct comparision.
2011-06-24 22:57:14 +04:00
dnl #
dnl # 2.6.39 API change,
dnl # Owner type change. A Linux mutex prior to 2.6.39 would store
dnl # the owner as a thread_info pointer when CONFIG_DEBUG_MUTEXES
dnl # was defined. As of 2.6.39 this was changed to a task_struct
dnl # pointer which frankly makes a lot more sense.
dnl #
AC_DEFUN([SPL_AC_MUTEX_OWNER_TASK_STRUCT], [
AC_MSG_CHECKING([whether struct mutex owner is a task_struct])
tmp_flags="$EXTRA_KCFLAGS"
EXTRA_KCFLAGS="-Werror"
SPL_LINUX_TRY_COMPILE([
#include <linux/mutex.h>
Fix HAVE_MUTEX_OWNER_TASK_STRUCT autotools check on PPC64 The HAVE_MUTEX_OWNER_TASK_STRUCT fails on PPC64 with the following error: error: 'current' undeclared (first use in this function) We include linux/sched.h to ensure that current is available. Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-02-06 01:42:29 +04:00
#include <linux/sched.h>
Linux 2.6.39 compat, mutex owner Prior to Linux 2.6.39 when CONFIG_DEBUG_MUTEXES was defined the kernel stored a thread_info pointer as the mutex owner. From this you could get the pointer of the current task_struct to compare with get_current(). As of Linux 2.6.39 this behavior has changed and now the mutex stores a pointer to the task_struct. This commit detects the type of pointer stored in the mutex and adjusts the mutex_owner() and mutex_owned() functions to perform the correct comparision.
2011-06-24 22:57:14 +04:00
],[
struct mutex mtx __attribute__ ((unused));
mtx.owner = current;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_MUTEX_OWNER_TASK_STRUCT, 1,
[struct mutex owner is a task_struct])
],[
AC_MSG_RESULT(no)
])
EXTRA_KCFLAGS="$tmp_flags"
])
SLES10 Fixes (part 3): - Configure check for mutex_lock_nested(). This function was introduced as part of the mutex validator in 2.6.18, but if it's unavailable then it's safe to fallback to a plain mutex_lock().
2009-05-20 21:56:13 +04:00
dnl #
dnl # 2.6.18 API change,
dnl # First introduced 'mutex_lock_nested()' in include/linux/mutex.h,
dnl # as part of the mutex validator. Fallback to using 'mutex_lock()'
dnl # if the mutex validator is disabled or otherwise unavailable.
dnl #
AC_DEFUN([SPL_AC_MUTEX_LOCK_NESTED], [
AC_MSG_CHECKING([whether mutex_lock_nested() is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/mutex.h>
],[
struct mutex mutex;
mutex_init(&mutex);
mutex_lock_nested(&mutex, 0);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_MUTEX_LOCK_NESTED, 1,
[mutex_lock_nested() is available])
],[
AC_MSG_RESULT(no)
])
])
2.6.27+ portability changes - Added SPL_AC_3ARGS_ON_EACH_CPU configure check to determine if the older 4 argument version of on_each_cpu() should be used or the new 3 argument version. The retry argument was dropped in the new API which was never used anyway. - Updated work queue compatibility wrappers. The old way this worked was to pass a data point when initialized the workqueue. The new API assumed the work item is embedding in a structure and we us container_of() to find that data pointer. - Updated skc->skc_flags to be an unsigned long which is now type checked in the bit operations. This silences the warnings. - Updated autogen products and splat tests accordingly
2009-02-03 02:12:30 +03:00
dnl #
dnl # 2.6.27 API change,
dnl # on_each_cpu() uses 3 args, no 'retry' argument
dnl #
AC_DEFUN([SPL_AC_3ARGS_ON_EACH_CPU], [
AC_MSG_CHECKING([whether on_each_cpu() wants 3 args])
SPL_LINUX_TRY_COMPILE([
Linux compat 3.7.1, on_each_cpu() Some kernels require that we include the 'linux/irqflags.h' header for the SPL_AC_3ARGS_ON_EACH_CPU check. Otherwise, the functions local_irq_enable()/local_irq_disable() will not be defined and the prototype will be misdetected as the four argument version. This change actually include 'linux/interrupt.h' which in turn includes 'linux/irqflags.h' to be as generic as possible. Additionally, passing NULL as the function can result in a gcc error because the on_each_cpu() macro executes it unconditionally. To make the test more robust we pass the dummy function on_each_cpu_func(). Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #204
2013-01-08 02:09:09 +04:00
#include <linux/interrupt.h>
2.6.27+ portability changes - Added SPL_AC_3ARGS_ON_EACH_CPU configure check to determine if the older 4 argument version of on_each_cpu() should be used or the new 3 argument version. The retry argument was dropped in the new API which was never used anyway. - Updated work queue compatibility wrappers. The old way this worked was to pass a data point when initialized the workqueue. The new API assumed the work item is embedding in a structure and we us container_of() to find that data pointer. - Updated skc->skc_flags to be an unsigned long which is now type checked in the bit operations. This silences the warnings. - Updated autogen products and splat tests accordingly
2009-02-03 02:12:30 +03:00
#include <linux/smp.h>
Linux compat 3.7.1, on_each_cpu() Some kernels require that we include the 'linux/irqflags.h' header for the SPL_AC_3ARGS_ON_EACH_CPU check. Otherwise, the functions local_irq_enable()/local_irq_disable() will not be defined and the prototype will be misdetected as the four argument version. This change actually include 'linux/interrupt.h' which in turn includes 'linux/irqflags.h' to be as generic as possible. Additionally, passing NULL as the function can result in a gcc error because the on_each_cpu() macro executes it unconditionally. To make the test more robust we pass the dummy function on_each_cpu_func(). Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #204
2013-01-08 02:09:09 +04:00
void on_each_cpu_func(void *data) { return; }
2.6.27+ portability changes - Added SPL_AC_3ARGS_ON_EACH_CPU configure check to determine if the older 4 argument version of on_each_cpu() should be used or the new 3 argument version. The retry argument was dropped in the new API which was never used anyway. - Updated work queue compatibility wrappers. The old way this worked was to pass a data point when initialized the workqueue. The new API assumed the work item is embedding in a structure and we us container_of() to find that data pointer. - Updated skc->skc_flags to be an unsigned long which is now type checked in the bit operations. This silences the warnings. - Updated autogen products and splat tests accordingly
2009-02-03 02:12:30 +03:00
],[
Linux compat 3.7.1, on_each_cpu() Some kernels require that we include the 'linux/irqflags.h' header for the SPL_AC_3ARGS_ON_EACH_CPU check. Otherwise, the functions local_irq_enable()/local_irq_disable() will not be defined and the prototype will be misdetected as the four argument version. This change actually include 'linux/interrupt.h' which in turn includes 'linux/irqflags.h' to be as generic as possible. Additionally, passing NULL as the function can result in a gcc error because the on_each_cpu() macro executes it unconditionally. To make the test more robust we pass the dummy function on_each_cpu_func(). Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #204
2013-01-08 02:09:09 +04:00
on_each_cpu(on_each_cpu_func, NULL, 0);
2.6.27+ portability changes - Added SPL_AC_3ARGS_ON_EACH_CPU configure check to determine if the older 4 argument version of on_each_cpu() should be used or the new 3 argument version. The retry argument was dropped in the new API which was never used anyway. - Updated work queue compatibility wrappers. The old way this worked was to pass a data point when initialized the workqueue. The new API assumed the work item is embedding in a structure and we us container_of() to find that data pointer. - Updated skc->skc_flags to be an unsigned long which is now type checked in the bit operations. This silences the warnings. - Updated autogen products and splat tests accordingly
2009-02-03 02:12:30 +03:00
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_3ARGS_ON_EACH_CPU, 1,
[on_each_cpu wants 3 args])
],[
AC_MSG_RESULT(no)
])
])
Linux VM integration / device special files Support added to provide reasonable values for the global Solaris VM variables: minfree, desfree, lotsfree, needfree. These values are set to the sum of their per-zone linux counterparts which should be close enough for Solaris consumers. When a non-GPL app links against the SPL we cannot use the udev interfaces, which means non of the device special files are created. Because of this I had added a poor mans udev which cause the SPL to invoke an upcall and create the basic devices when a minor is registered. When a minor is unregistered we use the vnode interface to unlink the special file.
2009-02-05 02:15:41 +03:00
dnl #
Linux VM Integration Cleanup Remove all instances of functions being reimplemented in the SPL. When the prototypes are available in the linux headers but the function address itself is not exported use kallsyms_lookup_name() to find the address. The function name itself can them become a define which calls a function pointer. This is preferable to reimplementing the function in the SPL because it ensures we get the correct version of the function for the running kernel. This is actually pretty safe because the prototype is defined in the headers so we know we are calling the function properly. This patch also includes a rhel5 kernel patch we exports the needed symbols so we don't need to use kallsyms_lookup_name(). There are autoconf checks to detect if the symbol is exported and if so to use it directly. We should add patches for stock upstream kernels as needed if for no other reason than so we can easily track which additional symbols we needed exported. Those patches can also be used by anyone willing to rebuild their kernel, but this should not be a requirement. The rhel5 version of the export-symbols patch has been applied to the chaos kernel. Additional fixes: 1) Implement vmem_size() function using get_vmalloc_info() 2) SPL_CHECK_SYMBOL_EXPORT macro updated to use $LINUX_OBJ instead of $LINUX because Module.symvers is a build product. When $LINUX_OBJ != $LINUX we will not properly detect exported symbols. 3) SPL_LINUX_COMPILE_IFELSE macro updated to add include2 and $LINUX/include search paths to allow proper compilation when the kernel target build directory is not the source directory.
2009-02-26 00:20:40 +03:00
dnl # 2.6.18 API change,
dnl # kallsyms_lookup_name no longer exported
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_KALLSYMS_LOOKUP_NAME],
[AC_MSG_CHECKING([whether kallsyms_lookup_name() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/kallsyms.h>
], [
kallsyms_lookup_name(NULL);
], [kallsyms_lookup_name], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_KALLSYMS_LOOKUP_NAME, 1,
[kallsyms_lookup_name() is available])
], [
AC_MSG_RESULT(no)
])
Linux VM Integration Cleanup Remove all instances of functions being reimplemented in the SPL. When the prototypes are available in the linux headers but the function address itself is not exported use kallsyms_lookup_name() to find the address. The function name itself can them become a define which calls a function pointer. This is preferable to reimplementing the function in the SPL because it ensures we get the correct version of the function for the running kernel. This is actually pretty safe because the prototype is defined in the headers so we know we are calling the function properly. This patch also includes a rhel5 kernel patch we exports the needed symbols so we don't need to use kallsyms_lookup_name(). There are autoconf checks to detect if the symbol is exported and if so to use it directly. We should add patches for stock upstream kernels as needed if for no other reason than so we can easily track which additional symbols we needed exported. Those patches can also be used by anyone willing to rebuild their kernel, but this should not be a requirement. The rhel5 version of the export-symbols patch has been applied to the chaos kernel. Additional fixes: 1) Implement vmem_size() function using get_vmalloc_info() 2) SPL_CHECK_SYMBOL_EXPORT macro updated to use $LINUX_OBJ instead of $LINUX because Module.symvers is a build product. When $LINUX_OBJ != $LINUX we will not properly detect exported symbols. 3) SPL_LINUX_COMPILE_IFELSE macro updated to add include2 and $LINUX/include search paths to allow proper compilation when the kernel target build directory is not the source directory.
2009-02-26 00:20:40 +03:00
])
dnl #
FC10/i686 Compatibility Update (2.6.27.19-170.2.35.fc10.i686) In the interests of portability I have added a FC10/i686 box to my list of development platforms. The hope is this will allow me to keep current with upstream kernel API changes, and at the same time ensure I don't accidentally break x86 support. This patch resolves all remaining issues observed under that environment. 1) SPL_AC_ZONE_STAT_ITEM_FIA autoconf check added. As of 2.6.21 the kernel added a clean API for modules to get the global count for free, inactive, and active pages. The SPL attempts to detect if this API is available and directly map spl_global_page_state() to global_page_state(). If the full API is not available then spl_global_page_state() is implemented as a thin layer to get these values via get_zone_counts() if that symbol is available. 2) New kmem:vmem_size regression test added to validate correct vmem_size() functionality. The test case acquires the current global vmem state, allocates from the vmem region, then verifies the allocation is correctly reflected in the vmem_size() stats. 3) Change splat_kmem_cache_thread_test() to always use KMC_KMEM based memory. On x86 systems with limited virtual address space failures resulted due to exhaustig the address space. The tests really need to problem exhausting all memory on the system thus we need to use the physical address space. 4) Change kmem:slab_lock to cap it's memory usage at availrmem instead of using the native linux nr_free_pages(). This provides additional test coverage of the SPL Linux VM integration. 5) Change kmem:slab_overcommit to perform allocation of 256K instead of 1M. On x86 based systems it is not possible to create a kmem backed slab with entires of that size. To compensate for this the number of allocations performed in increased by 4x. 6) Additional autoconf documentation for proposed upstream API changes to make additional symbols available to modules. 7) Console error messages added when spl_kallsyms_lookup_name() fails to locate an expected symbol. This causes the module to fail to load and we need to know exactly which symbol was not available.
2009-03-17 22:16:31 +03:00
dnl # Proposed API change,
dnl # This symbol is not available in stock kernels. You may build a
dnl # custom kernel with the *-spl-export-symbols.patch which will export
dnl # these symbols for use. If your already rolling a custom kernel for
dnl # your environment this is recommended.
Linux VM Integration Cleanup Remove all instances of functions being reimplemented in the SPL. When the prototypes are available in the linux headers but the function address itself is not exported use kallsyms_lookup_name() to find the address. The function name itself can them become a define which calls a function pointer. This is preferable to reimplementing the function in the SPL because it ensures we get the correct version of the function for the running kernel. This is actually pretty safe because the prototype is defined in the headers so we know we are calling the function properly. This patch also includes a rhel5 kernel patch we exports the needed symbols so we don't need to use kallsyms_lookup_name(). There are autoconf checks to detect if the symbol is exported and if so to use it directly. We should add patches for stock upstream kernels as needed if for no other reason than so we can easily track which additional symbols we needed exported. Those patches can also be used by anyone willing to rebuild their kernel, but this should not be a requirement. The rhel5 version of the export-symbols patch has been applied to the chaos kernel. Additional fixes: 1) Implement vmem_size() function using get_vmalloc_info() 2) SPL_CHECK_SYMBOL_EXPORT macro updated to use $LINUX_OBJ instead of $LINUX because Module.symvers is a build product. When $LINUX_OBJ != $LINUX we will not properly detect exported symbols. 3) SPL_LINUX_COMPILE_IFELSE macro updated to add include2 and $LINUX/include search paths to allow proper compilation when the kernel target build directory is not the source directory.
2009-02-26 00:20:40 +03:00
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_GET_VMALLOC_INFO],
[AC_MSG_CHECKING([whether get_vmalloc_info() is available])
SPL_CHECK_SYMBOL_EXPORT([get_vmalloc_info], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_GET_VMALLOC_INFO, 1,
[get_vmalloc_info() is available])
], [
AC_MSG_RESULT(no)
])
Linux VM Integration Cleanup Remove all instances of functions being reimplemented in the SPL. When the prototypes are available in the linux headers but the function address itself is not exported use kallsyms_lookup_name() to find the address. The function name itself can them become a define which calls a function pointer. This is preferable to reimplementing the function in the SPL because it ensures we get the correct version of the function for the running kernel. This is actually pretty safe because the prototype is defined in the headers so we know we are calling the function properly. This patch also includes a rhel5 kernel patch we exports the needed symbols so we don't need to use kallsyms_lookup_name(). There are autoconf checks to detect if the symbol is exported and if so to use it directly. We should add patches for stock upstream kernels as needed if for no other reason than so we can easily track which additional symbols we needed exported. Those patches can also be used by anyone willing to rebuild their kernel, but this should not be a requirement. The rhel5 version of the export-symbols patch has been applied to the chaos kernel. Additional fixes: 1) Implement vmem_size() function using get_vmalloc_info() 2) SPL_CHECK_SYMBOL_EXPORT macro updated to use $LINUX_OBJ instead of $LINUX because Module.symvers is a build product. When $LINUX_OBJ != $LINUX we will not properly detect exported symbols. 3) SPL_LINUX_COMPILE_IFELSE macro updated to add include2 and $LINUX/include search paths to allow proper compilation when the kernel target build directory is not the source directory.
2009-02-26 00:20:40 +03:00
])
Linux 3.10 compat: struct vmalloc_info moved Linux kernel commmit torvalds/linux@db3808c1 moved the vmalloc_info structure from a private to a public header. Now that it's available for kernel modules use it. Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #257
2013-05-14 04:31:53 +04:00
dnl #
dnl # 3.10 API change,
dnl # struct vmalloc_info is now declared in linux/vmalloc.h
dnl #
AC_DEFUN([SPL_AC_VMALLOC_INFO], [
AC_MSG_CHECKING([whether struct vmalloc_info is declared])
SPL_LINUX_TRY_COMPILE([
#include <linux/vmalloc.h>
struct vmalloc_info { void *a; };
],[
return 0;
],[
AC_MSG_RESULT(no)
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_VMALLOC_INFO, 1, [yes])
])
])
Linux 3.10 compat: replace PDE()->data with PDE_DATA() Linux kernel commit torvalds/linux@d9dda78b renamed PDE() to PDE_DATA(). To handle this detect the prefered interface and define a PDE_DATA() wrapper for consistency. Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com> Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #257
2013-05-14 04:39:26 +04:00
dnl #
dnl # 3.10 API change,
dnl # PDE is replaced by PDE_DATA
dnl #
AC_DEFUN([SPL_AC_PDE_DATA], [
AC_MSG_CHECKING([whether PDE_DATA() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/proc_fs.h>
], [
PDE_DATA(NULL);
], [PDE_DATA], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_PDE_DATA, 1, [yes])
],[
AC_MSG_RESULT(no)
])
])
SLES10 Fixes (part 6) - Prior to 2.6.17 there were no *_pgdat helper functions in mm/mmzone.c. Instead for_each_zone() operated directly on pgdat_list which may or may not have been exported depending on how your kernel was compiled. Now new configure checks determine if you have the helpers or not, and if the needed symbols are exported. If they are not exported then they are dynamically aquired at runtime by kallsyms_lookup_name().
2009-05-21 01:23:13 +04:00
dnl #
dnl # 2.6.17 API change
dnl # The helper functions first_online_pgdat(), next_online_pgdat(), and
dnl # next_zone() are introduced to simplify for_each_zone(). These symbols
dnl # were exported in 2.6.17 for use by modules which was consistent with
dnl # the previous implementation of for_each_zone(). From 2.6.18 - 2.6.19
dnl # the symbols were exported as 'unused', and by 2.6.20 they exports
dnl # were dropped entirely leaving modules no way to directly iterate over
dnl # the zone list. Because we need access to the zone helpers we check
dnl # if the kernel contains the old or new implementation. Then we check
dnl # to see if the symbols we need for each version are available. If they
dnl # are not, dynamically aquire the addresses with kallsyms_lookup_name().
dnl #
AC_DEFUN([SPL_AC_PGDAT_HELPERS], [
AC_MSG_CHECKING([whether symbol *_pgdat exist])
grep -q -E 'first_online_pgdat' $LINUX/include/linux/mmzone.h 2>/dev/null
rc=$?
if test $rc -eq 0; then
AC_MSG_RESULT([yes])
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFINE(HAVE_PGDAT_HELPERS, 1, [pgdat helpers are available])
SLES10 Fixes (part 6) - Prior to 2.6.17 there were no *_pgdat helper functions in mm/mmzone.c. Instead for_each_zone() operated directly on pgdat_list which may or may not have been exported depending on how your kernel was compiled. Now new configure checks determine if you have the helpers or not, and if the needed symbols are exported. If they are not exported then they are dynamically aquired at runtime by kallsyms_lookup_name().
2009-05-21 01:23:13 +04:00
else
AC_MSG_RESULT([no])
fi
])
Linux VM Integration Cleanup Remove all instances of functions being reimplemented in the SPL. When the prototypes are available in the linux headers but the function address itself is not exported use kallsyms_lookup_name() to find the address. The function name itself can them become a define which calls a function pointer. This is preferable to reimplementing the function in the SPL because it ensures we get the correct version of the function for the running kernel. This is actually pretty safe because the prototype is defined in the headers so we know we are calling the function properly. This patch also includes a rhel5 kernel patch we exports the needed symbols so we don't need to use kallsyms_lookup_name(). There are autoconf checks to detect if the symbol is exported and if so to use it directly. We should add patches for stock upstream kernels as needed if for no other reason than so we can easily track which additional symbols we needed exported. Those patches can also be used by anyone willing to rebuild their kernel, but this should not be a requirement. The rhel5 version of the export-symbols patch has been applied to the chaos kernel. Additional fixes: 1) Implement vmem_size() function using get_vmalloc_info() 2) SPL_CHECK_SYMBOL_EXPORT macro updated to use $LINUX_OBJ instead of $LINUX because Module.symvers is a build product. When $LINUX_OBJ != $LINUX we will not properly detect exported symbols. 3) SPL_LINUX_COMPILE_IFELSE macro updated to add include2 and $LINUX/include search paths to allow proper compilation when the kernel target build directory is not the source directory.
2009-02-26 00:20:40 +03:00
dnl #
FC10/i686 Compatibility Update (2.6.27.19-170.2.35.fc10.i686) In the interests of portability I have added a FC10/i686 box to my list of development platforms. The hope is this will allow me to keep current with upstream kernel API changes, and at the same time ensure I don't accidentally break x86 support. This patch resolves all remaining issues observed under that environment. 1) SPL_AC_ZONE_STAT_ITEM_FIA autoconf check added. As of 2.6.21 the kernel added a clean API for modules to get the global count for free, inactive, and active pages. The SPL attempts to detect if this API is available and directly map spl_global_page_state() to global_page_state(). If the full API is not available then spl_global_page_state() is implemented as a thin layer to get these values via get_zone_counts() if that symbol is available. 2) New kmem:vmem_size regression test added to validate correct vmem_size() functionality. The test case acquires the current global vmem state, allocates from the vmem region, then verifies the allocation is correctly reflected in the vmem_size() stats. 3) Change splat_kmem_cache_thread_test() to always use KMC_KMEM based memory. On x86 systems with limited virtual address space failures resulted due to exhaustig the address space. The tests really need to problem exhausting all memory on the system thus we need to use the physical address space. 4) Change kmem:slab_lock to cap it's memory usage at availrmem instead of using the native linux nr_free_pages(). This provides additional test coverage of the SPL Linux VM integration. 5) Change kmem:slab_overcommit to perform allocation of 256K instead of 1M. On x86 based systems it is not possible to create a kmem backed slab with entires of that size. To compensate for this the number of allocations performed in increased by 4x. 6) Additional autoconf documentation for proposed upstream API changes to make additional symbols available to modules. 7) Console error messages added when spl_kallsyms_lookup_name() fails to locate an expected symbol. This causes the module to fail to load and we need to know exactly which symbol was not available.
2009-03-17 22:16:31 +03:00
dnl # Proposed API change,
dnl # This symbol is not available in stock kernels. You may build a
dnl # custom kernel with the *-spl-export-symbols.patch which will export
dnl # these symbols for use. If your already rolling a custom kernel for
dnl # your environment this is recommended.
Linux VM integration / device special files Support added to provide reasonable values for the global Solaris VM variables: minfree, desfree, lotsfree, needfree. These values are set to the sum of their per-zone linux counterparts which should be close enough for Solaris consumers. When a non-GPL app links against the SPL we cannot use the udev interfaces, which means non of the device special files are created. Because of this I had added a poor mans udev which cause the SPL to invoke an upcall and create the basic devices when a minor is registered. When a minor is unregistered we use the vnode interface to unlink the special file.
2009-02-05 02:15:41 +03:00
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_FIRST_ONLINE_PGDAT],
[AC_MSG_CHECKING([whether first_online_pgdat() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/mmzone.h>
], [
first_online_pgdat();
], [first_online_pgdat], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_FIRST_ONLINE_PGDAT, 1,
[first_online_pgdat() is available])
], [
AC_MSG_RESULT(no)
])
Linux VM integration / device special files Support added to provide reasonable values for the global Solaris VM variables: minfree, desfree, lotsfree, needfree. These values are set to the sum of their per-zone linux counterparts which should be close enough for Solaris consumers. When a non-GPL app links against the SPL we cannot use the udev interfaces, which means non of the device special files are created. Because of this I had added a poor mans udev which cause the SPL to invoke an upcall and create the basic devices when a minor is registered. When a minor is unregistered we use the vnode interface to unlink the special file.
2009-02-05 02:15:41 +03:00
])
dnl #
FC10/i686 Compatibility Update (2.6.27.19-170.2.35.fc10.i686) In the interests of portability I have added a FC10/i686 box to my list of development platforms. The hope is this will allow me to keep current with upstream kernel API changes, and at the same time ensure I don't accidentally break x86 support. This patch resolves all remaining issues observed under that environment. 1) SPL_AC_ZONE_STAT_ITEM_FIA autoconf check added. As of 2.6.21 the kernel added a clean API for modules to get the global count for free, inactive, and active pages. The SPL attempts to detect if this API is available and directly map spl_global_page_state() to global_page_state(). If the full API is not available then spl_global_page_state() is implemented as a thin layer to get these values via get_zone_counts() if that symbol is available. 2) New kmem:vmem_size regression test added to validate correct vmem_size() functionality. The test case acquires the current global vmem state, allocates from the vmem region, then verifies the allocation is correctly reflected in the vmem_size() stats. 3) Change splat_kmem_cache_thread_test() to always use KMC_KMEM based memory. On x86 systems with limited virtual address space failures resulted due to exhaustig the address space. The tests really need to problem exhausting all memory on the system thus we need to use the physical address space. 4) Change kmem:slab_lock to cap it's memory usage at availrmem instead of using the native linux nr_free_pages(). This provides additional test coverage of the SPL Linux VM integration. 5) Change kmem:slab_overcommit to perform allocation of 256K instead of 1M. On x86 based systems it is not possible to create a kmem backed slab with entires of that size. To compensate for this the number of allocations performed in increased by 4x. 6) Additional autoconf documentation for proposed upstream API changes to make additional symbols available to modules. 7) Console error messages added when spl_kallsyms_lookup_name() fails to locate an expected symbol. This causes the module to fail to load and we need to know exactly which symbol was not available.
2009-03-17 22:16:31 +03:00
dnl # Proposed API change,
dnl # This symbol is not available in stock kernels. You may build a
dnl # custom kernel with the *-spl-export-symbols.patch which will export
dnl # these symbols for use. If your already rolling a custom kernel for
dnl # your environment this is recommended.
Linux VM integration / device special files Support added to provide reasonable values for the global Solaris VM variables: minfree, desfree, lotsfree, needfree. These values are set to the sum of their per-zone linux counterparts which should be close enough for Solaris consumers. When a non-GPL app links against the SPL we cannot use the udev interfaces, which means non of the device special files are created. Because of this I had added a poor mans udev which cause the SPL to invoke an upcall and create the basic devices when a minor is registered. When a minor is unregistered we use the vnode interface to unlink the special file.
2009-02-05 02:15:41 +03:00
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_NEXT_ONLINE_PGDAT],
[AC_MSG_CHECKING([whether next_online_pgdat() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/mmzone.h>
], [
next_online_pgdat(NULL);
], [next_online_pgdat], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_NEXT_ONLINE_PGDAT, 1,
[next_online_pgdat() is available])
], [
AC_MSG_RESULT(no)
])
Linux VM integration / device special files Support added to provide reasonable values for the global Solaris VM variables: minfree, desfree, lotsfree, needfree. These values are set to the sum of their per-zone linux counterparts which should be close enough for Solaris consumers. When a non-GPL app links against the SPL we cannot use the udev interfaces, which means non of the device special files are created. Because of this I had added a poor mans udev which cause the SPL to invoke an upcall and create the basic devices when a minor is registered. When a minor is unregistered we use the vnode interface to unlink the special file.
2009-02-05 02:15:41 +03:00
])
dnl #
FC10/i686 Compatibility Update (2.6.27.19-170.2.35.fc10.i686) In the interests of portability I have added a FC10/i686 box to my list of development platforms. The hope is this will allow me to keep current with upstream kernel API changes, and at the same time ensure I don't accidentally break x86 support. This patch resolves all remaining issues observed under that environment. 1) SPL_AC_ZONE_STAT_ITEM_FIA autoconf check added. As of 2.6.21 the kernel added a clean API for modules to get the global count for free, inactive, and active pages. The SPL attempts to detect if this API is available and directly map spl_global_page_state() to global_page_state(). If the full API is not available then spl_global_page_state() is implemented as a thin layer to get these values via get_zone_counts() if that symbol is available. 2) New kmem:vmem_size regression test added to validate correct vmem_size() functionality. The test case acquires the current global vmem state, allocates from the vmem region, then verifies the allocation is correctly reflected in the vmem_size() stats. 3) Change splat_kmem_cache_thread_test() to always use KMC_KMEM based memory. On x86 systems with limited virtual address space failures resulted due to exhaustig the address space. The tests really need to problem exhausting all memory on the system thus we need to use the physical address space. 4) Change kmem:slab_lock to cap it's memory usage at availrmem instead of using the native linux nr_free_pages(). This provides additional test coverage of the SPL Linux VM integration. 5) Change kmem:slab_overcommit to perform allocation of 256K instead of 1M. On x86 based systems it is not possible to create a kmem backed slab with entires of that size. To compensate for this the number of allocations performed in increased by 4x. 6) Additional autoconf documentation for proposed upstream API changes to make additional symbols available to modules. 7) Console error messages added when spl_kallsyms_lookup_name() fails to locate an expected symbol. This causes the module to fail to load and we need to know exactly which symbol was not available.
2009-03-17 22:16:31 +03:00
dnl # Proposed API change,
dnl # This symbol is not available in stock kernels. You may build a
dnl # custom kernel with the *-spl-export-symbols.patch which will export
dnl # these symbols for use. If your already rolling a custom kernel for
dnl # your environment this is recommended.
Linux VM integration / device special files Support added to provide reasonable values for the global Solaris VM variables: minfree, desfree, lotsfree, needfree. These values are set to the sum of their per-zone linux counterparts which should be close enough for Solaris consumers. When a non-GPL app links against the SPL we cannot use the udev interfaces, which means non of the device special files are created. Because of this I had added a poor mans udev which cause the SPL to invoke an upcall and create the basic devices when a minor is registered. When a minor is unregistered we use the vnode interface to unlink the special file.
2009-02-05 02:15:41 +03:00
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_NEXT_ZONE],
[AC_MSG_CHECKING([whether next_zone() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/mmzone.h>
], [
next_zone(NULL);
], [next_zone], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_NEXT_ZONE, 1, [next_zone() is available])
], [
AC_MSG_RESULT(no)
])
Linux VM integration / device special files Support added to provide reasonable values for the global Solaris VM variables: minfree, desfree, lotsfree, needfree. These values are set to the sum of their per-zone linux counterparts which should be close enough for Solaris consumers. When a non-GPL app links against the SPL we cannot use the udev interfaces, which means non of the device special files are created. Because of this I had added a poor mans udev which cause the SPL to invoke an upcall and create the basic devices when a minor is registered. When a minor is unregistered we use the vnode interface to unlink the special file.
2009-02-05 02:15:41 +03:00
])
Additional Linux VM integration Added support for Solaris swapfs_minfree, and swapfs_reserve tunables. In additional availrmem is now available and return a reasonable value which is reasonably analogous to the Solaris meaning. On linux we return the sun of free and inactive pages since these are all easily reclaimable. All tunables are available in /proc/sys/kernel/spl/vm/* and they may need a little adjusting once we observe the real behavior. Some of the defaults are mapped to similar linux counterparts, others are straight from the OpenSolaris defaults.
2009-02-05 23:26:34 +03:00
SLES10 Fixes (part 6) - Prior to 2.6.17 there were no *_pgdat helper functions in mm/mmzone.c. Instead for_each_zone() operated directly on pgdat_list which may or may not have been exported depending on how your kernel was compiled. Now new configure checks determine if you have the helpers or not, and if the needed symbols are exported. If they are not exported then they are dynamically aquired at runtime by kallsyms_lookup_name().
2009-05-21 01:23:13 +04:00
dnl #
dnl # 2.6.17 API change,
dnl # See SPL_AC_PGDAT_HELPERS for details.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_PGDAT_LIST],
[AC_MSG_CHECKING([whether pgdat_list is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/topology.h>
pg_data_t *tmp = pgdat_list;
], [], [pgdat_list], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_PGDAT_LIST, 1, [pgdat_list is available])
], [
AC_MSG_RESULT(no)
])
SLES10 Fixes (part 6) - Prior to 2.6.17 there were no *_pgdat helper functions in mm/mmzone.c. Instead for_each_zone() operated directly on pgdat_list which may or may not have been exported depending on how your kernel was compiled. Now new configure checks determine if you have the helpers or not, and if the needed symbols are exported. If they are not exported then they are dynamically aquired at runtime by kallsyms_lookup_name().
2009-05-21 01:23:13 +04:00
])
SLES10 Fixes (part 2): - Configure check, the div64_64() function was renamed to div64_u64() as of 2.6.26. - Configure check, the global_page_state() fuction was introduced in 2.6.18 kernels. The earlier 2.6.16 based SLES10 must not try and use it, thankfully get_zone_counts() is still available. - To simplify debugging poison all symbols aquired dynamically using spl_kallsyms_lookup_name() with SYMBOL_POISON. - Add console messages when the user mode helpers fail. - spl_kmem_init_globals() use bit shifts instead of division. - When the monotonic clock is unavailable __gethrtime() must perform the HZ division as an 'unsigned long long' because the SPL only implements __udivdi3(), and not __divdi3() for 'long long' division on 32-bit arches.
2009-05-20 21:08:37 +04:00
dnl #
dnl # 2.6.18 API change,
dnl # First introduced global_page_state() support as an inline.
dnl #
AC_DEFUN([SPL_AC_GLOBAL_PAGE_STATE], [
AC_MSG_CHECKING([whether global_page_state() is available])
SPL_LINUX_TRY_COMPILE([
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
#include <linux/mm.h>
SLES10 Fixes (part 2): - Configure check, the div64_64() function was renamed to div64_u64() as of 2.6.26. - Configure check, the global_page_state() fuction was introduced in 2.6.18 kernels. The earlier 2.6.16 based SLES10 must not try and use it, thankfully get_zone_counts() is still available. - To simplify debugging poison all symbols aquired dynamically using spl_kallsyms_lookup_name() with SYMBOL_POISON. - Add console messages when the user mode helpers fail. - spl_kmem_init_globals() use bit shifts instead of division. - When the monotonic clock is unavailable __gethrtime() must perform the HZ division as an 'unsigned long long' because the SPL only implements __udivdi3(), and not __divdi3() for 'long long' division on 32-bit arches.
2009-05-20 21:08:37 +04:00
],[
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.
2011-04-19 20:26:48 +04:00
unsigned long state __attribute__ ((unused));
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
state = global_page_state(0);
SLES10 Fixes (part 2): - Configure check, the div64_64() function was renamed to div64_u64() as of 2.6.26. - Configure check, the global_page_state() fuction was introduced in 2.6.18 kernels. The earlier 2.6.16 based SLES10 must not try and use it, thankfully get_zone_counts() is still available. - To simplify debugging poison all symbols aquired dynamically using spl_kallsyms_lookup_name() with SYMBOL_POISON. - Add console messages when the user mode helpers fail. - spl_kmem_init_globals() use bit shifts instead of division. - When the monotonic clock is unavailable __gethrtime() must perform the HZ division as an 'unsigned long long' because the SPL only implements __udivdi3(), and not __divdi3() for 'long long' division on 32-bit arches.
2009-05-20 21:08:37 +04:00
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_GLOBAL_PAGE_STATE, 1,
[global_page_state() is available])
],[
AC_MSG_RESULT(no)
])
])
FC10/i686 Compatibility Update (2.6.27.19-170.2.35.fc10.i686) In the interests of portability I have added a FC10/i686 box to my list of development platforms. The hope is this will allow me to keep current with upstream kernel API changes, and at the same time ensure I don't accidentally break x86 support. This patch resolves all remaining issues observed under that environment. 1) SPL_AC_ZONE_STAT_ITEM_FIA autoconf check added. As of 2.6.21 the kernel added a clean API for modules to get the global count for free, inactive, and active pages. The SPL attempts to detect if this API is available and directly map spl_global_page_state() to global_page_state(). If the full API is not available then spl_global_page_state() is implemented as a thin layer to get these values via get_zone_counts() if that symbol is available. 2) New kmem:vmem_size regression test added to validate correct vmem_size() functionality. The test case acquires the current global vmem state, allocates from the vmem region, then verifies the allocation is correctly reflected in the vmem_size() stats. 3) Change splat_kmem_cache_thread_test() to always use KMC_KMEM based memory. On x86 systems with limited virtual address space failures resulted due to exhaustig the address space. The tests really need to problem exhausting all memory on the system thus we need to use the physical address space. 4) Change kmem:slab_lock to cap it's memory usage at availrmem instead of using the native linux nr_free_pages(). This provides additional test coverage of the SPL Linux VM integration. 5) Change kmem:slab_overcommit to perform allocation of 256K instead of 1M. On x86 based systems it is not possible to create a kmem backed slab with entires of that size. To compensate for this the number of allocations performed in increased by 4x. 6) Additional autoconf documentation for proposed upstream API changes to make additional symbols available to modules. 7) Console error messages added when spl_kallsyms_lookup_name() fails to locate an expected symbol. This causes the module to fail to load and we need to know exactly which symbol was not available.
2009-03-17 22:16:31 +03:00
dnl #
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
dnl # 2.6.21 API change (plus subsequent naming convention changes),
dnl # Public global zone stats now include a free page count. However
dnl # the enumerated names of the counters have changed since this API
dnl # was introduced. We need to deduce the corrent name to use. This
dnl # replaces the priviate get_zone_counts() interface.
dnl #
dnl # NR_FREE_PAGES was available from 2.6.21 to current kernels, which
dnl # is 2.6.30 as of when this was written.
FC10/i686 Compatibility Update (2.6.27.19-170.2.35.fc10.i686) In the interests of portability I have added a FC10/i686 box to my list of development platforms. The hope is this will allow me to keep current with upstream kernel API changes, and at the same time ensure I don't accidentally break x86 support. This patch resolves all remaining issues observed under that environment. 1) SPL_AC_ZONE_STAT_ITEM_FIA autoconf check added. As of 2.6.21 the kernel added a clean API for modules to get the global count for free, inactive, and active pages. The SPL attempts to detect if this API is available and directly map spl_global_page_state() to global_page_state(). If the full API is not available then spl_global_page_state() is implemented as a thin layer to get these values via get_zone_counts() if that symbol is available. 2) New kmem:vmem_size regression test added to validate correct vmem_size() functionality. The test case acquires the current global vmem state, allocates from the vmem region, then verifies the allocation is correctly reflected in the vmem_size() stats. 3) Change splat_kmem_cache_thread_test() to always use KMC_KMEM based memory. On x86 systems with limited virtual address space failures resulted due to exhaustig the address space. The tests really need to problem exhausting all memory on the system thus we need to use the physical address space. 4) Change kmem:slab_lock to cap it's memory usage at availrmem instead of using the native linux nr_free_pages(). This provides additional test coverage of the SPL Linux VM integration. 5) Change kmem:slab_overcommit to perform allocation of 256K instead of 1M. On x86 based systems it is not possible to create a kmem backed slab with entires of that size. To compensate for this the number of allocations performed in increased by 4x. 6) Additional autoconf documentation for proposed upstream API changes to make additional symbols available to modules. 7) Console error messages added when spl_kallsyms_lookup_name() fails to locate an expected symbol. This causes the module to fail to load and we need to know exactly which symbol was not available.
2009-03-17 22:16:31 +03:00
dnl #
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
AC_DEFUN([SPL_AC_ZONE_STAT_ITEM_FREE], [
AC_MSG_CHECKING([whether page state NR_FREE_PAGES is available])
FC10/i686 Compatibility Update (2.6.27.19-170.2.35.fc10.i686) In the interests of portability I have added a FC10/i686 box to my list of development platforms. The hope is this will allow me to keep current with upstream kernel API changes, and at the same time ensure I don't accidentally break x86 support. This patch resolves all remaining issues observed under that environment. 1) SPL_AC_ZONE_STAT_ITEM_FIA autoconf check added. As of 2.6.21 the kernel added a clean API for modules to get the global count for free, inactive, and active pages. The SPL attempts to detect if this API is available and directly map spl_global_page_state() to global_page_state(). If the full API is not available then spl_global_page_state() is implemented as a thin layer to get these values via get_zone_counts() if that symbol is available. 2) New kmem:vmem_size regression test added to validate correct vmem_size() functionality. The test case acquires the current global vmem state, allocates from the vmem region, then verifies the allocation is correctly reflected in the vmem_size() stats. 3) Change splat_kmem_cache_thread_test() to always use KMC_KMEM based memory. On x86 systems with limited virtual address space failures resulted due to exhaustig the address space. The tests really need to problem exhausting all memory on the system thus we need to use the physical address space. 4) Change kmem:slab_lock to cap it's memory usage at availrmem instead of using the native linux nr_free_pages(). This provides additional test coverage of the SPL Linux VM integration. 5) Change kmem:slab_overcommit to perform allocation of 256K instead of 1M. On x86 based systems it is not possible to create a kmem backed slab with entires of that size. To compensate for this the number of allocations performed in increased by 4x. 6) Additional autoconf documentation for proposed upstream API changes to make additional symbols available to modules. 7) Console error messages added when spl_kallsyms_lookup_name() fails to locate an expected symbol. This causes the module to fail to load and we need to know exactly which symbol was not available.
2009-03-17 22:16:31 +03:00
SPL_LINUX_TRY_COMPILE([
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
#include <linux/mm.h>
FC10/i686 Compatibility Update (2.6.27.19-170.2.35.fc10.i686) In the interests of portability I have added a FC10/i686 box to my list of development platforms. The hope is this will allow me to keep current with upstream kernel API changes, and at the same time ensure I don't accidentally break x86 support. This patch resolves all remaining issues observed under that environment. 1) SPL_AC_ZONE_STAT_ITEM_FIA autoconf check added. As of 2.6.21 the kernel added a clean API for modules to get the global count for free, inactive, and active pages. The SPL attempts to detect if this API is available and directly map spl_global_page_state() to global_page_state(). If the full API is not available then spl_global_page_state() is implemented as a thin layer to get these values via get_zone_counts() if that symbol is available. 2) New kmem:vmem_size regression test added to validate correct vmem_size() functionality. The test case acquires the current global vmem state, allocates from the vmem region, then verifies the allocation is correctly reflected in the vmem_size() stats. 3) Change splat_kmem_cache_thread_test() to always use KMC_KMEM based memory. On x86 systems with limited virtual address space failures resulted due to exhaustig the address space. The tests really need to problem exhausting all memory on the system thus we need to use the physical address space. 4) Change kmem:slab_lock to cap it's memory usage at availrmem instead of using the native linux nr_free_pages(). This provides additional test coverage of the SPL Linux VM integration. 5) Change kmem:slab_overcommit to perform allocation of 256K instead of 1M. On x86 based systems it is not possible to create a kmem backed slab with entires of that size. To compensate for this the number of allocations performed in increased by 4x. 6) Additional autoconf documentation for proposed upstream API changes to make additional symbols available to modules. 7) Console error messages added when spl_kallsyms_lookup_name() fails to locate an expected symbol. This causes the module to fail to load and we need to know exactly which symbol was not available.
2009-03-17 22:16:31 +03:00
],[
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.
2011-04-19 20:26:48 +04:00
enum zone_stat_item zsi __attribute__ ((unused));
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
zsi = NR_FREE_PAGES;
FC10/i686 Compatibility Update (2.6.27.19-170.2.35.fc10.i686) In the interests of portability I have added a FC10/i686 box to my list of development platforms. The hope is this will allow me to keep current with upstream kernel API changes, and at the same time ensure I don't accidentally break x86 support. This patch resolves all remaining issues observed under that environment. 1) SPL_AC_ZONE_STAT_ITEM_FIA autoconf check added. As of 2.6.21 the kernel added a clean API for modules to get the global count for free, inactive, and active pages. The SPL attempts to detect if this API is available and directly map spl_global_page_state() to global_page_state(). If the full API is not available then spl_global_page_state() is implemented as a thin layer to get these values via get_zone_counts() if that symbol is available. 2) New kmem:vmem_size regression test added to validate correct vmem_size() functionality. The test case acquires the current global vmem state, allocates from the vmem region, then verifies the allocation is correctly reflected in the vmem_size() stats. 3) Change splat_kmem_cache_thread_test() to always use KMC_KMEM based memory. On x86 systems with limited virtual address space failures resulted due to exhaustig the address space. The tests really need to problem exhausting all memory on the system thus we need to use the physical address space. 4) Change kmem:slab_lock to cap it's memory usage at availrmem instead of using the native linux nr_free_pages(). This provides additional test coverage of the SPL Linux VM integration. 5) Change kmem:slab_overcommit to perform allocation of 256K instead of 1M. On x86 based systems it is not possible to create a kmem backed slab with entires of that size. To compensate for this the number of allocations performed in increased by 4x. 6) Additional autoconf documentation for proposed upstream API changes to make additional symbols available to modules. 7) Console error messages added when spl_kallsyms_lookup_name() fails to locate an expected symbol. This causes the module to fail to load and we need to know exactly which symbol was not available.
2009-03-17 22:16:31 +03:00
],[
AC_MSG_RESULT(yes)
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
AC_DEFINE(HAVE_ZONE_STAT_ITEM_NR_FREE_PAGES, 1,
[Page state NR_FREE_PAGES is available])
FC10/i686 Compatibility Update (2.6.27.19-170.2.35.fc10.i686) In the interests of portability I have added a FC10/i686 box to my list of development platforms. The hope is this will allow me to keep current with upstream kernel API changes, and at the same time ensure I don't accidentally break x86 support. This patch resolves all remaining issues observed under that environment. 1) SPL_AC_ZONE_STAT_ITEM_FIA autoconf check added. As of 2.6.21 the kernel added a clean API for modules to get the global count for free, inactive, and active pages. The SPL attempts to detect if this API is available and directly map spl_global_page_state() to global_page_state(). If the full API is not available then spl_global_page_state() is implemented as a thin layer to get these values via get_zone_counts() if that symbol is available. 2) New kmem:vmem_size regression test added to validate correct vmem_size() functionality. The test case acquires the current global vmem state, allocates from the vmem region, then verifies the allocation is correctly reflected in the vmem_size() stats. 3) Change splat_kmem_cache_thread_test() to always use KMC_KMEM based memory. On x86 systems with limited virtual address space failures resulted due to exhaustig the address space. The tests really need to problem exhausting all memory on the system thus we need to use the physical address space. 4) Change kmem:slab_lock to cap it's memory usage at availrmem instead of using the native linux nr_free_pages(). This provides additional test coverage of the SPL Linux VM integration. 5) Change kmem:slab_overcommit to perform allocation of 256K instead of 1M. On x86 based systems it is not possible to create a kmem backed slab with entires of that size. To compensate for this the number of allocations performed in increased by 4x. 6) Additional autoconf documentation for proposed upstream API changes to make additional symbols available to modules. 7) Console error messages added when spl_kallsyms_lookup_name() fails to locate an expected symbol. This causes the module to fail to load and we need to know exactly which symbol was not available.
2009-03-17 22:16:31 +03:00
],[
AC_MSG_RESULT(no)
])
])
SLES10 Fixes (part 4): - Configure check for SLES specific API change to vfs_unlink() and vfs_rename() which added a 'struct vfsmount *' argument. This was for something called the linux-security-module, but it appears that it was never adopted upstream.
2009-05-20 22:31:55 +04:00
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
dnl #
dnl # 2.6.21 API change (plus subsequent naming convention changes),
dnl # Public global zone stats now include an inactive page count. However
dnl # the enumerated names of the counters have changed since this API
dnl # was introduced. We need to deduce the corrent name to use. This
dnl # replaces the priviate get_zone_counts() interface.
dnl #
dnl # NR_INACTIVE was available from 2.6.21 to 2.6.27 and included both
dnl # anonymous and file inactive pages. As of 2.6.28 it was split in
dnl # to NR_INACTIVE_ANON and NR_INACTIVE_FILE.
dnl #
AC_DEFUN([SPL_AC_ZONE_STAT_ITEM_INACTIVE], [
AC_MSG_CHECKING([whether page state NR_INACTIVE is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
],[
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.
2011-04-19 20:26:48 +04:00
enum zone_stat_item zsi __attribute__ ((unused));
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
zsi = NR_INACTIVE;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_ZONE_STAT_ITEM_NR_INACTIVE, 1,
[Page state NR_INACTIVE is available])
],[
AC_MSG_RESULT(no)
])
AC_MSG_CHECKING([whether page state NR_INACTIVE_ANON is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
],[
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.
2011-04-19 20:26:48 +04:00
enum zone_stat_item zsi __attribute__ ((unused));
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
zsi = NR_INACTIVE_ANON;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_ZONE_STAT_ITEM_NR_INACTIVE_ANON, 1,
[Page state NR_INACTIVE_ANON is available])
],[
AC_MSG_RESULT(no)
])
AC_MSG_CHECKING([whether page state NR_INACTIVE_FILE is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
],[
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.
2011-04-19 20:26:48 +04:00
enum zone_stat_item zsi __attribute__ ((unused));
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
zsi = NR_INACTIVE_FILE;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_ZONE_STAT_ITEM_NR_INACTIVE_FILE, 1,
[Page state NR_INACTIVE_FILE is available])
],[
AC_MSG_RESULT(no)
])
])
dnl #
dnl # 2.6.21 API change (plus subsequent naming convention changes),
dnl # Public global zone stats now include an active page count. However
dnl # the enumerated names of the counters have changed since this API
dnl # was introduced. We need to deduce the corrent name to use. This
dnl # replaces the priviate get_zone_counts() interface.
dnl #
dnl # NR_ACTIVE was available from 2.6.21 to 2.6.27 and included both
dnl # anonymous and file active pages. As of 2.6.28 it was split in
dnl # to NR_ACTIVE_ANON and NR_ACTIVE_FILE.
dnl #
AC_DEFUN([SPL_AC_ZONE_STAT_ITEM_ACTIVE], [
AC_MSG_CHECKING([whether page state NR_ACTIVE is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
],[
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.
2011-04-19 20:26:48 +04:00
enum zone_stat_item zsi __attribute__ ((unused));
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
zsi = NR_ACTIVE;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_ZONE_STAT_ITEM_NR_ACTIVE, 1,
[Page state NR_ACTIVE is available])
],[
AC_MSG_RESULT(no)
])
AC_MSG_CHECKING([whether page state NR_ACTIVE_ANON is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
],[
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.
2011-04-19 20:26:48 +04:00
enum zone_stat_item zsi __attribute__ ((unused));
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
zsi = NR_ACTIVE_ANON;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_ZONE_STAT_ITEM_NR_ACTIVE_ANON, 1,
[Page state NR_ACTIVE_ANON is available])
],[
AC_MSG_RESULT(no)
])
AC_MSG_CHECKING([whether page state NR_ACTIVE_FILE is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
],[
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.
2011-04-19 20:26:48 +04:00
enum zone_stat_item zsi __attribute__ ((unused));
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
zsi = NR_ACTIVE_FILE;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_ZONE_STAT_ITEM_NR_ACTIVE_FILE, 1,
[Page state NR_ACTIVE_FILE is available])
],[
AC_MSG_RESULT(no)
])
])
dnl #
dnl # Proposed API change for legacy kernels.
dnl # This symbol is not available in older kernels. For kernels post
dnl # 2.6.21 the global_page_state() API is used to get free/inactive/active
dnl # page state information. This symbol is only used in legacy kernels
dnl # any only as a last resort.
dnl
AC_DEFUN([SPL_AC_GET_ZONE_COUNTS], [
AC_MSG_CHECKING([whether symbol get_zone_counts is needed])
SPL_LINUX_TRY_COMPILE([
],[
#if !defined(HAVE_ZONE_STAT_ITEM_NR_FREE_PAGES)
#error "global_page_state needs NR_FREE_PAGES"
#endif
#if !defined(HAVE_ZONE_STAT_ITEM_NR_ACTIVE) && \
!defined(HAVE_ZONE_STAT_ITEM_NR_ACTIVE_ANON) && \
!defined(HAVE_ZONE_STAT_ITEM_NR_ACTIVE_FILE)
#error "global_page_state needs NR_ACTIVE*"
#endif
#if !defined(HAVE_ZONE_STAT_ITEM_NR_INACTIVE) && \
!defined(HAVE_ZONE_STAT_ITEM_NR_INACTIVE_ANON) && \
!defined(HAVE_ZONE_STAT_ITEM_NR_INACTIVE_FILE)
#error "global_page_state needs NR_INACTIVE*"
#endif
],[
AC_MSG_RESULT(no)
],[
AC_MSG_RESULT(yes)
AC_DEFINE(NEED_GET_ZONE_COUNTS, 1,
[get_zone_counts() is needed])
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_MSG_CHECKING([whether get_zone_counts() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/mmzone.h>
], [
get_zone_counts(NULL, NULL, NULL);
], [get_zone_counts], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_GET_ZONE_COUNTS, 1,
[get_zone_counts() is available])
], [
AC_MSG_RESULT(no)
])
Update global_page_state() support for 2.6.29 kernels. Basically everything we need to monitor the global memory state of the system is now cleanly available via global_page_state(). The problem is that this interface is still fairly recent, and there has been one change in the page state enum which we need to handle. These changes basically boil down to the following: - If global_page_state() is available we should use it. Several autoconf checks have been added to detect the correct enum names. - If global_page_state() is not available check to see if get_zone_counts() symbol is available and use that. - If the get_zone_counts() symbol is not exported we have no choice be to dynamically aquire it at load time. This is an absolute last resort for old kernel which we don't want to patch to cleanly export the symbol.
2009-07-29 02:06:42 +04:00
])
])
Add configure check for user_path_dir() I didn't notice at the time but user_path_dir() was not introduced at the same time as set_fs_pwd() change. I had lumped the two together but in fact user_path_dir() was introduced in 2.6.27 and set_fs_pwd() taking 2 args was introduced in 2.6.25. This means builds against 2.6.25-2.6.26 kernels were broken. To fix this I've added a check for user_path_dir() and no longer assume that if set_fs_pwd() takes 2 args then user_path_dir() is also available.
2010-07-02 00:37:43 +04:00
dnl #
dnl # 2.6.27 API change,
dnl # The user_path_dir() replaces __user_walk()
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_USER_PATH_DIR],
[AC_MSG_CHECKING([whether user_path_dir() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/fcntl.h>
#include <linux/namei.h>
], [
user_path_dir(NULL, NULL);
], [user_path_at], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_USER_PATH_DIR, 1, [user_path_dir() is available])
], [
AC_MSG_RESULT(no)
])
Add configure check for user_path_dir() I didn't notice at the time but user_path_dir() was not introduced at the same time as set_fs_pwd() change. I had lumped the two together but in fact user_path_dir() was introduced in 2.6.27 and set_fs_pwd() taking 2 args was introduced in 2.6.25. This means builds against 2.6.25-2.6.26 kernels were broken. To fix this I've added a check for user_path_dir() and no longer assume that if set_fs_pwd() takes 2 args then user_path_dir() is also available.
2010-07-02 00:37:43 +04:00
])
Set cwd to '/' for the process executing insmod. Ricardo has pointed out that under Solaris the cwd is set to '/' during module load, while under Linux it is set to the callers cwd. To handle this cleanly I've reworked the module *_init()/_exit() macros so they call a *_setup()/_cleanup() function when any SPL dependent module is loaded or unloaded. This gives us a chance to perform any needed modification of the process, in this case changing the cwd. It also handily provides a way to avoid creating wrapper init()/exit() functions because the Solaris and Linux prototypes differ slightly. All dependent modules should now call the spl helper macros spl_module_{init,exit}() instead of the native linux versions. Unfortunately, it appears that under Linux there has been no consistent API in the kernel to set the cwd in a module. Because of this I have had to add more autoconf magic than I'd like. However, what I have done is correct and has been tested on RHEL5, SLES11, FC11, and CHAOS kernels. In addition, I have change the rootdir type from a 'void *' to the correct 'vnode_t *' type. And I've set rootdir to a non-NULL value.
2009-10-02 03:06:15 +04:00
dnl #
dnl # Symbol available in RHEL kernels not in stock kernels.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_SET_FS_PWD],
[AC_MSG_CHECKING([whether set_fs_pwd() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/spinlock.h>
#include <linux/fs_struct.h>
], [
(void) set_fs_pwd;
], [set_fs_pwd], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_SET_FS_PWD, 1, [set_fs_pwd() is available])
], [
AC_MSG_RESULT(no)
])
Set cwd to '/' for the process executing insmod. Ricardo has pointed out that under Solaris the cwd is set to '/' during module load, while under Linux it is set to the callers cwd. To handle this cleanly I've reworked the module *_init()/_exit() macros so they call a *_setup()/_cleanup() function when any SPL dependent module is loaded or unloaded. This gives us a chance to perform any needed modification of the process, in this case changing the cwd. It also handily provides a way to avoid creating wrapper init()/exit() functions because the Solaris and Linux prototypes differ slightly. All dependent modules should now call the spl helper macros spl_module_{init,exit}() instead of the native linux versions. Unfortunately, it appears that under Linux there has been no consistent API in the kernel to set the cwd in a module. Because of this I have had to add more autoconf magic than I'd like. However, what I have done is correct and has been tested on RHEL5, SLES11, FC11, and CHAOS kernels. In addition, I have change the rootdir type from a 'void *' to the correct 'vnode_t *' type. And I've set rootdir to a non-NULL value.
2009-10-02 03:06:15 +04:00
])
Linux 3.9 compat: set_fs_root takes const struct path * torvalds/linux@dcf787f39162ce32ca325b3e784aba2d2444619a enforces const-correctness in passing struct path *. Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-03-04 09:24:04 +04:00
dnl #
dnl # 3.9 API change
dnl # set_fs_pwd takes const struct path *
dnl #
AC_DEFUN([SPL_AC_SET_FS_PWD_WITH_CONST],
tmp_flags="$EXTRA_KCFLAGS"
EXTRA_KCFLAGS="-Werror"
[AC_MSG_CHECKING([whether set_fs_pwd() requires const struct path *])
SPL_LINUX_TRY_COMPILE([
#include <linux/spinlock.h>
#include <linux/fs_struct.h>
#include <linux/path.h>
void (*const set_fs_pwd_func)
(struct fs_struct *, const struct path *)
= set_fs_pwd;
],[
return 0;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_SET_FS_PWD_WITH_CONST, 1,
[set_fs_pwd() needs const path *])
],[
SPL_LINUX_TRY_COMPILE([
#include <linux/spinlock.h>
#include <linux/fs_struct.h>
#include <linux/path.h>
void (*const set_fs_pwd_func)
(struct fs_struct *, struct path *)
= set_fs_pwd;
],[
return 0;
],[
AC_MSG_RESULT(no)
],[
AC_MSG_ERROR(unknown)
])
])
EXTRA_KCFLAGS="$tmp_flags"
])
SLES10 Fixes (part 4): - Configure check for SLES specific API change to vfs_unlink() and vfs_rename() which added a 'struct vfsmount *' argument. This was for something called the linux-security-module, but it appears that it was never adopted upstream.
2009-05-20 22:31:55 +04:00
AC_DEFUN([SPL_AC_2ARGS_VFS_UNLINK],
[AC_MSG_CHECKING([whether vfs_unlink() wants 2 args])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
Linux 3.13 compat: Pass NULL for new delegated inode argument This check was originally added for SLES10, a093c6a, to check for a 'struct vfsmount *' argument which they added. However, since SLES10 is based on a 2.6.16 kernel which is no longer supported this functionality was dropped. The checks were refactored to support Linux 3.13 without concern for historical versions. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #312
2013-11-25 20:22:33 +04:00
vfs_unlink((struct inode *) NULL, (struct dentry *) NULL);
SLES10 Fixes (part 4): - Configure check for SLES specific API change to vfs_unlink() and vfs_rename() which added a 'struct vfsmount *' argument. This was for something called the linux-security-module, but it appears that it was never adopted upstream.
2009-05-20 22:31:55 +04:00
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_2ARGS_VFS_UNLINK, 1,
[vfs_unlink() wants 2 args])
],[
AC_MSG_RESULT(no)
Linux 3.13 compat: Pass NULL for new delegated inode argument This check was originally added for SLES10, a093c6a, to check for a 'struct vfsmount *' argument which they added. However, since SLES10 is based on a 2.6.16 kernel which is no longer supported this functionality was dropped. The checks were refactored to support Linux 3.13 without concern for historical versions. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #312
2013-11-25 20:22:33 +04:00
dnl #
dnl # Linux 3.13 API change
dnl # Added delegated inode
dnl #
AC_MSG_CHECKING([whether vfs_unlink() wants 3 args])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
vfs_unlink((struct inode *) NULL,
(struct dentry *) NULL,
(struct inode **) NULL);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_3ARGS_VFS_UNLINK, 1,
[vfs_unlink() wants 3 args])
],[
AC_MSG_ERROR(no)
])
SLES10 Fixes (part 4): - Configure check for SLES specific API change to vfs_unlink() and vfs_rename() which added a 'struct vfsmount *' argument. This was for something called the linux-security-module, but it appears that it was never adopted upstream.
2009-05-20 22:31:55 +04:00
])
])
AC_DEFUN([SPL_AC_4ARGS_VFS_RENAME],
[AC_MSG_CHECKING([whether vfs_rename() wants 4 args])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
Linux 3.13 compat: Pass NULL for new delegated inode argument This check was originally added for SLES10, a093c6a, to check for a 'struct vfsmount *' argument which they added. However, since SLES10 is based on a 2.6.16 kernel which is no longer supported this functionality was dropped. The checks were refactored to support Linux 3.13 without concern for historical versions. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #312
2013-11-25 20:22:33 +04:00
vfs_rename((struct inode *) NULL, (struct dentry *) NULL,
(struct inode *) NULL, (struct dentry *) NULL);
SLES10 Fixes (part 4): - Configure check for SLES specific API change to vfs_unlink() and vfs_rename() which added a 'struct vfsmount *' argument. This was for something called the linux-security-module, but it appears that it was never adopted upstream.
2009-05-20 22:31:55 +04:00
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_4ARGS_VFS_RENAME, 1,
[vfs_rename() wants 4 args])
],[
AC_MSG_RESULT(no)
Linux 3.13 compat: Pass NULL for new delegated inode argument This check was originally added for SLES10, a093c6a, to check for a 'struct vfsmount *' argument which they added. However, since SLES10 is based on a 2.6.16 kernel which is no longer supported this functionality was dropped. The checks were refactored to support Linux 3.13 without concern for historical versions. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #312
2013-11-25 20:22:33 +04:00
dnl #
dnl # Linux 3.13 API change
dnl # Added delegated inode
dnl #
AC_MSG_CHECKING([whether vfs_rename() wants 5 args])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
vfs_rename((struct inode *) NULL,
(struct dentry *) NULL,
(struct inode *) NULL,
(struct dentry *) NULL,
(struct inode **) NULL);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_5ARGS_VFS_RENAME, 1,
[vfs_rename() wants 5 args])
],[
Linux 3.15: vfs_rename() added a flags argument Detect the updated vfs_rename() interface and call it with an extra flags argument. References: torvalds/linux@520c8b1 Signed-off-by: Chunwei Chen <tuxoko@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #355
2014-05-07 21:54:37 +04:00
AC_MSG_RESULT(no)
dnl #
dnl # Linux 3.15 API change
dnl # Added flags
dnl #
AC_MSG_CHECKING([whether vfs_rename() wants 6 args])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
vfs_rename((struct inode *) NULL,
(struct dentry *) NULL,
(struct inode *) NULL,
(struct dentry *) NULL,
(struct inode **) NULL,
(unsigned int) 0);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_6ARGS_VFS_RENAME, 1,
[vfs_rename() wants 6 args])
],[
AC_MSG_ERROR(no)
])
Linux 3.13 compat: Pass NULL for new delegated inode argument This check was originally added for SLES10, a093c6a, to check for a 'struct vfsmount *' argument which they added. However, since SLES10 is based on a 2.6.16 kernel which is no longer supported this functionality was dropped. The checks were refactored to support Linux 3.13 without concern for historical versions. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #312
2013-11-25 20:22:33 +04:00
])
SLES10 Fixes (part 4): - Configure check for SLES specific API change to vfs_unlink() and vfs_rename() which added a 'struct vfsmount *' argument. This was for something called the linux-security-module, but it appears that it was never adopted upstream.
2009-05-20 22:31:55 +04:00
])
])
Add basic credential support and splat tests. The previous credential implementation simply provided the needed types and a couple of dummy functions needed. This update correctly ties the basic Solaris credential API in to one of two Linux kernel APIs. Prior to 2.6.29 the linux kernel embeded all credentials in the task structure. For these kernels, we pass around the entire task struct as if it were the credential, then we use the helper functions to extract the credential related bits. As of 2.6.29 a new credential type was added which we can and do fairly cleanly layer on top of. Once again the helper functions nicely hide the implementation details from all callers. Three tests were added to the splat test framework to verify basic correctness. They should be extended as needed when need credential functions are added.
2009-07-28 04:18:59 +04:00
Linux 2.6.36 compat, fs_struct->lock type change In the linux-2.6.36 kernel the fs_struct lock was changed from a rwlock_t to a spinlock_t. If the kernel would export the set_fs_pwd() symbol by default this would not have caused us any issues, but they don't. So we're forced to add a new autoconf check which sets the HAVE_FS_STRUCT_SPINLOCK define when a spinlock_t is used. We can then correctly use either spin_lock or write_lock in our custom set_fs_pwd() implementation.
2010-11-09 22:15:32 +03:00
dnl #
dnl # 2.6.36 API change,
dnl # The 'struct fs_struct->lock' was changed from a rwlock_t to
dnl # a spinlock_t to improve the fastpath performance.
dnl #
AC_DEFUN([SPL_AC_FS_STRUCT_SPINLOCK], [
AC_MSG_CHECKING([whether struct fs_struct uses spinlock_t])
Fix HAVE_FS_STRUCT_SPINLOCK check for gcc-4.1.2 Older versions of gcc (gcc-4.1.2) will treat an 'incompatible pointer type' as a warning instead of an error. This results in HAVE_FS_STRUCT_SPINLOCK being defined incorrectly. This failure mode was observed when using a RHEL6 2.6.32 based kernel under RHEL5.5 which contains the old version of gcc. To resolve the issue the warning is explicitly promoted to an error. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2011-09-20 00:35:03 +04:00
tmp_flags="$EXTRA_KCFLAGS"
EXTRA_KCFLAGS="-Werror"
Linux 2.6.36 compat, fs_struct->lock type change In the linux-2.6.36 kernel the fs_struct lock was changed from a rwlock_t to a spinlock_t. If the kernel would export the set_fs_pwd() symbol by default this would not have caused us any issues, but they don't. So we're forced to add a new autoconf check which sets the HAVE_FS_STRUCT_SPINLOCK define when a spinlock_t is used. We can then correctly use either spin_lock or write_lock in our custom set_fs_pwd() implementation.
2010-11-09 22:15:32 +03:00
SPL_LINUX_TRY_COMPILE([
#include <linux/sched.h>
#include <linux/fs_struct.h>
],[
struct fs_struct fs;
spin_lock_init(&fs.lock);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_FS_STRUCT_SPINLOCK, 1,
[struct fs_struct uses spinlock_t])
],[
AC_MSG_RESULT(no)
])
Fix HAVE_FS_STRUCT_SPINLOCK check for gcc-4.1.2 Older versions of gcc (gcc-4.1.2) will treat an 'incompatible pointer type' as a warning instead of an error. This results in HAVE_FS_STRUCT_SPINLOCK being defined incorrectly. This failure mode was observed when using a RHEL6 2.6.32 based kernel under RHEL5.5 which contains the old version of gcc. To resolve the issue the warning is explicitly promoted to an error. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2011-09-20 00:35:03 +04:00
EXTRA_KCFLAGS="$tmp_flags"
Linux 2.6.36 compat, fs_struct->lock type change In the linux-2.6.36 kernel the fs_struct lock was changed from a rwlock_t to a spinlock_t. If the kernel would export the set_fs_pwd() symbol by default this would not have caused us any issues, but they don't. So we're forced to add a new autoconf check which sets the HAVE_FS_STRUCT_SPINLOCK define when a spinlock_t is used. We can then correctly use either spin_lock or write_lock in our custom set_fs_pwd() implementation.
2010-11-09 22:15:32 +03:00
])
Add basic credential support and splat tests. The previous credential implementation simply provided the needed types and a couple of dummy functions needed. This update correctly ties the basic Solaris credential API in to one of two Linux kernel APIs. Prior to 2.6.29 the linux kernel embeded all credentials in the task structure. For these kernels, we pass around the entire task struct as if it were the credential, then we use the helper functions to extract the credential related bits. As of 2.6.29 a new credential type was added which we can and do fairly cleanly layer on top of. Once again the helper functions nicely hide the implementation details from all callers. Three tests were added to the splat test framework to verify basic correctness. They should be extended as needed when need credential functions are added.
2009-07-28 04:18:59 +04:00
dnl #
dnl # 2.6.29 API change,
dnl # check whether 'struct cred' exists
dnl #
AC_DEFUN([SPL_AC_CRED_STRUCT], [
AC_MSG_CHECKING([whether struct cred exists])
SPL_LINUX_TRY_COMPILE([
#include <linux/cred.h>
],[
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.
2011-04-19 20:26:48 +04:00
struct cred *cr __attribute__ ((unused));
Add basic credential support and splat tests. The previous credential implementation simply provided the needed types and a couple of dummy functions needed. This update correctly ties the basic Solaris credential API in to one of two Linux kernel APIs. Prior to 2.6.29 the linux kernel embeded all credentials in the task structure. For these kernels, we pass around the entire task struct as if it were the credential, then we use the helper functions to extract the credential related bits. As of 2.6.29 a new credential type was added which we can and do fairly cleanly layer on top of. Once again the helper functions nicely hide the implementation details from all callers. Three tests were added to the splat test framework to verify basic correctness. They should be extended as needed when need credential functions are added.
2009-07-28 04:18:59 +04:00
cr = NULL;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_CRED_STRUCT, 1, [struct cred exists])
],[
AC_MSG_RESULT(no)
])
])
Linux 3.8 compat: Use kuid_t/kgid_t when required When CONFIG_UIDGID_STRICT_TYPE_CHECKS is enabled uid_t/git_t are replaced by kuid_t/kgid_t, which are structures instead of integral types. This causes any code that uses an integral type to fail to build. The User Namespace functionality introduced in Linux 3.8 requires CONFIG_UIDGID_STRICT_TYPE_CHECKS, so we could not build against any kernel that supported it. We resolve this by converting between the new kuid_t/kgid_t structures and the original uid_t/gid_t types. Original-patch-by: DHE Rewrite-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #260
2013-07-14 00:34:56 +04:00
dnl #
dnl # User namespaces, use kuid_t in place of uid_t
dnl # where available. Not strictly a user namespaces thing
dnl # but it should prevent surprises
dnl #
AC_DEFUN([SPL_AC_KUIDGID_T], [
AC_MSG_CHECKING([whether kuid_t/kgid_t is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/uidgid.h>
], [
kuid_t userid = KUIDT_INIT(0);
kgid_t groupid = KGIDT_INIT(0);
],[
SPL_LINUX_TRY_COMPILE([
#include <linux/uidgid.h>
], [
kuid_t userid = 0;
kgid_t groupid = 0;
],[
AC_MSG_RESULT(yes; optional)
],[
AC_MSG_RESULT(yes; mandatory)
AC_DEFINE(HAVE_KUIDGID_T, 1, [kuid_t/kgid_t in use])
])
],[
AC_MSG_RESULT(no)
])
])
Add basic credential support and splat tests. The previous credential implementation simply provided the needed types and a couple of dummy functions needed. This update correctly ties the basic Solaris credential API in to one of two Linux kernel APIs. Prior to 2.6.29 the linux kernel embeded all credentials in the task structure. For these kernels, we pass around the entire task struct as if it were the credential, then we use the helper functions to extract the credential related bits. As of 2.6.29 a new credential type was added which we can and do fairly cleanly layer on top of. Once again the helper functions nicely hide the implementation details from all callers. Three tests were added to the splat test framework to verify basic correctness. They should be extended as needed when need credential functions are added.
2009-07-28 04:18:59 +04:00
dnl #
Reimplement rwlocks for Linux lock profiling/analysis. It turns out that the previous rwlock implementation worked well but did not integrate properly with the upstream kernel lock profiling/ analysis tools. This is a major problem since it would be awfully nice to be able to use the automatic lock checker and profiler. The problem is that the upstream lock tools use the pre-processor to create a lock class for each uniquely named locked. Since the rwsem was embedded in a wrapper structure the name was always the same. The effect was that we only ended up with one lock class for the entire SPL which caused the lock dependency checker to flag nearly everything as a possible deadlock. The solution was to directly map a krwlock to a Linux rwsem using a typedef there by eliminating the wrapper structure. This was not done initially because the rwsem implementation is specific to the arch. To fully implement the Solaris krwlock API using only the provided rwsem API is not possible. It can only be done by directly accessing some of the internal data member of the rwsem structure. For example, the Linux API provides a different function for dropping a reader vs writer lock. Whereas the Solaris API uses the same function and the caller does not pass in what type of lock it is. This means to properly drop the lock we need to determine if the lock is currently a reader or writer lock. Then we need to call the proper Linux API function. Unfortunately, there is no provided API for this so we must extracted this information directly from arch specific lock implementation. This is all do able, and what I did, but it does complicate things considerably. The good news is that in addition to the profiling benefits of this change. We may see performance improvements due to slightly reduced overhead when creating rwlocks and manipulating them. The only function I was forced to sacrafice was rw_owner() because this information is simply not stored anywhere in the rwsem. Luckily this appears not to be a commonly used function on Solaris, and it is my understanding it is mainly used for debugging anyway. In addition to the core rwlock changes, extensive updates were made to the rwlock regression tests. Each class of test was extended to provide more API coverage and to be more rigerous in checking for misbehavior. This is a pretty significant change and with that in mind I have been careful to validate it on several platforms before committing. The full SPLAT regression test suite was run numberous times on all of the following platforms. This includes various kernels ranging from 2.6.16 to 2.6.29. - SLES10 (ppc64) - SLES11 (x86_64) - CHAOS4.2 (x86_64) - RHEL5.3 (x86_64) - RHEL6 (x86_64) - FC11 (x86_64)
2009-09-19 03:09:47 +04:00
dnl # Custom SPL patch may export this symbol.
Add basic credential support and splat tests. The previous credential implementation simply provided the needed types and a couple of dummy functions needed. This update correctly ties the basic Solaris credential API in to one of two Linux kernel APIs. Prior to 2.6.29 the linux kernel embeded all credentials in the task structure. For these kernels, we pass around the entire task struct as if it were the credential, then we use the helper functions to extract the credential related bits. As of 2.6.29 a new credential type was added which we can and do fairly cleanly layer on top of. Once again the helper functions nicely hide the implementation details from all callers. Three tests were added to the splat test framework to verify basic correctness. They should be extended as needed when need credential functions are added.
2009-07-28 04:18:59 +04:00
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_GROUPS_SEARCH],
[AC_MSG_CHECKING([whether groups_search() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/cred.h>
Linux 3.8 compat: Use kuid_t/kgid_t when required When CONFIG_UIDGID_STRICT_TYPE_CHECKS is enabled uid_t/git_t are replaced by kuid_t/kgid_t, which are structures instead of integral types. This causes any code that uses an integral type to fail to build. The User Namespace functionality introduced in Linux 3.8 requires CONFIG_UIDGID_STRICT_TYPE_CHECKS, so we could not build against any kernel that supported it. We resolve this by converting between the new kuid_t/kgid_t structures and the original uid_t/gid_t types. Original-patch-by: DHE Rewrite-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #260
2013-07-14 00:34:56 +04:00
#ifdef HAVE_KUIDGID_T
#include <linux/uidgid.h>
#endif
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
], [
Linux 3.8 compat: Use kuid_t/kgid_t when required When CONFIG_UIDGID_STRICT_TYPE_CHECKS is enabled uid_t/git_t are replaced by kuid_t/kgid_t, which are structures instead of integral types. This causes any code that uses an integral type to fail to build. The User Namespace functionality introduced in Linux 3.8 requires CONFIG_UIDGID_STRICT_TYPE_CHECKS, so we could not build against any kernel that supported it. We resolve this by converting between the new kuid_t/kgid_t structures and the original uid_t/gid_t types. Original-patch-by: DHE Rewrite-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #260
2013-07-14 00:34:56 +04:00
#ifdef HAVE_KUIDGID_T
groups_search(NULL, KGIDT_INIT(0));
#else
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
groups_search(NULL, 0);
Linux 3.8 compat: Use kuid_t/kgid_t when required When CONFIG_UIDGID_STRICT_TYPE_CHECKS is enabled uid_t/git_t are replaced by kuid_t/kgid_t, which are structures instead of integral types. This causes any code that uses an integral type to fail to build. The User Namespace functionality introduced in Linux 3.8 requires CONFIG_UIDGID_STRICT_TYPE_CHECKS, so we could not build against any kernel that supported it. We resolve this by converting between the new kuid_t/kgid_t structures and the original uid_t/gid_t types. Original-patch-by: DHE Rewrite-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #260
2013-07-14 00:34:56 +04:00
#endif
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
], [groups_search], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_GROUPS_SEARCH, 1, [groups_search() is available])
], [
AC_MSG_RESULT(no)
])
Add basic credential support and splat tests. The previous credential implementation simply provided the needed types and a couple of dummy functions needed. This update correctly ties the basic Solaris credential API in to one of two Linux kernel APIs. Prior to 2.6.29 the linux kernel embeded all credentials in the task structure. For these kernels, we pass around the entire task struct as if it were the credential, then we use the helper functions to extract the credential related bits. As of 2.6.29 a new credential type was added which we can and do fairly cleanly layer on top of. Once again the helper functions nicely hide the implementation details from all callers. Three tests were added to the splat test framework to verify basic correctness. They should be extended as needed when need credential functions are added.
2009-07-28 04:18:59 +04:00
])
Reimplement rwlocks for Linux lock profiling/analysis. It turns out that the previous rwlock implementation worked well but did not integrate properly with the upstream kernel lock profiling/ analysis tools. This is a major problem since it would be awfully nice to be able to use the automatic lock checker and profiler. The problem is that the upstream lock tools use the pre-processor to create a lock class for each uniquely named locked. Since the rwsem was embedded in a wrapper structure the name was always the same. The effect was that we only ended up with one lock class for the entire SPL which caused the lock dependency checker to flag nearly everything as a possible deadlock. The solution was to directly map a krwlock to a Linux rwsem using a typedef there by eliminating the wrapper structure. This was not done initially because the rwsem implementation is specific to the arch. To fully implement the Solaris krwlock API using only the provided rwsem API is not possible. It can only be done by directly accessing some of the internal data member of the rwsem structure. For example, the Linux API provides a different function for dropping a reader vs writer lock. Whereas the Solaris API uses the same function and the caller does not pass in what type of lock it is. This means to properly drop the lock we need to determine if the lock is currently a reader or writer lock. Then we need to call the proper Linux API function. Unfortunately, there is no provided API for this so we must extracted this information directly from arch specific lock implementation. This is all do able, and what I did, but it does complicate things considerably. The good news is that in addition to the profiling benefits of this change. We may see performance improvements due to slightly reduced overhead when creating rwlocks and manipulating them. The only function I was forced to sacrafice was rw_owner() because this information is simply not stored anywhere in the rwsem. Luckily this appears not to be a commonly used function on Solaris, and it is my understanding it is mainly used for debugging anyway. In addition to the core rwlock changes, extensive updates were made to the rwlock regression tests. Each class of test was extended to provide more API coverage and to be more rigerous in checking for misbehavior. This is a pretty significant change and with that in mind I have been careful to validate it on several platforms before committing. The full SPLAT regression test suite was run numberous times on all of the following platforms. This includes various kernels ranging from 2.6.16 to 2.6.29. - SLES10 (ppc64) - SLES11 (x86_64) - CHAOS4.2 (x86_64) - RHEL5.3 (x86_64) - RHEL6 (x86_64) - FC11 (x86_64)
2009-09-19 03:09:47 +04:00
dnl #
dnl # 2.6.x API change,
dnl # __put_task_struct() was exported in RHEL5 but unavailable elsewhere.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_PUT_TASK_STRUCT],
[AC_MSG_CHECKING([whether __put_task_struct() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/sched.h>
], [
__put_task_struct(NULL);
], [__put_task_struct], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_PUT_TASK_STRUCT, 1,
[__put_task_struct() is available])
], [
AC_MSG_RESULT(no)
])
Reimplement rwlocks for Linux lock profiling/analysis. It turns out that the previous rwlock implementation worked well but did not integrate properly with the upstream kernel lock profiling/ analysis tools. This is a major problem since it would be awfully nice to be able to use the automatic lock checker and profiler. The problem is that the upstream lock tools use the pre-processor to create a lock class for each uniquely named locked. Since the rwsem was embedded in a wrapper structure the name was always the same. The effect was that we only ended up with one lock class for the entire SPL which caused the lock dependency checker to flag nearly everything as a possible deadlock. The solution was to directly map a krwlock to a Linux rwsem using a typedef there by eliminating the wrapper structure. This was not done initially because the rwsem implementation is specific to the arch. To fully implement the Solaris krwlock API using only the provided rwsem API is not possible. It can only be done by directly accessing some of the internal data member of the rwsem structure. For example, the Linux API provides a different function for dropping a reader vs writer lock. Whereas the Solaris API uses the same function and the caller does not pass in what type of lock it is. This means to properly drop the lock we need to determine if the lock is currently a reader or writer lock. Then we need to call the proper Linux API function. Unfortunately, there is no provided API for this so we must extracted this information directly from arch specific lock implementation. This is all do able, and what I did, but it does complicate things considerably. The good news is that in addition to the profiling benefits of this change. We may see performance improvements due to slightly reduced overhead when creating rwlocks and manipulating them. The only function I was forced to sacrafice was rw_owner() because this information is simply not stored anywhere in the rwsem. Luckily this appears not to be a commonly used function on Solaris, and it is my understanding it is mainly used for debugging anyway. In addition to the core rwlock changes, extensive updates were made to the rwlock regression tests. Each class of test was extended to provide more API coverage and to be more rigerous in checking for misbehavior. This is a pretty significant change and with that in mind I have been careful to validate it on several platforms before committing. The full SPLAT regression test suite was run numberous times on all of the following platforms. This includes various kernels ranging from 2.6.16 to 2.6.29. - SLES10 (ppc64) - SLES11 (x86_64) - CHAOS4.2 (x86_64) - RHEL5.3 (x86_64) - RHEL6 (x86_64) - FC11 (x86_64)
2009-09-19 03:09:47 +04:00
])
Linux 2.6.32 compat, proc_handler() API change As of linux-2.6.32 the 'struct file *filp' argument was dropped from the proc_handle() prototype. It was apparently unused _almost_ everywhere in the kernel and this was simply cleanup. I've added a new SPL_AC_5ARGS_PROC_HANDLER autoconf check for this and the proper compat macros to correctly define the prototypes and some helper functions. It's not pretty but API compat changes rarely are.
2010-03-04 23:14:56 +03:00
dnl #
dnl # 2.6.32 API change,
dnl # Unused 'struct file *' removed from prototype.
dnl #
AC_DEFUN([SPL_AC_5ARGS_PROC_HANDLER], [
AC_MSG_CHECKING([whether proc_handler() wants 5 args])
SPL_LINUX_TRY_COMPILE([
#include <linux/sysctl.h>
],[
proc_dostring(NULL, 0, NULL, NULL, NULL);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_5ARGS_PROC_HANDLER, 1,
[proc_handler() wants 5 args])
],[
AC_MSG_RESULT(no)
])
])
Add kmem_asprintf(), strfree(), strdup(), and minor cleanup. This patch adds three missing Solaris functions: kmem_asprintf(), strfree(), and strdup(). They are all implemented as a thin layer which just calls their Linux counterparts. As part of this an autoconf check for kvasprintf was added because it does not appear in older kernels. If the kernel does not provide it then spl-generic implements it. Additionally the dead DEBUG_KMEM_UNIMPLEMENTED code was removed to clean things up and make the kmem.h a little more readable.
2010-06-12 01:48:18 +04:00
dnl #
dnl # 2.6.x API change,
dnl # kvasprintf() function added.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_KVASPRINTF],
[AC_MSG_CHECKING([whether kvasprintf() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/kernel.h>
], [
kvasprintf(0, NULL, *((va_list*)NULL));
], [kvasprintf], [], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_KVASPRINTF, 1, [kvasprintf() is available])
], [
AC_MSG_RESULT(no)
])
Add kmem_asprintf(), strfree(), strdup(), and minor cleanup. This patch adds three missing Solaris functions: kmem_asprintf(), strfree(), and strdup(). They are all implemented as a thin layer which just calls their Linux counterparts. As part of this an autoconf check for kvasprintf was added because it does not appear in older kernels. If the kernel does not provide it then spl-generic implements it. Additionally the dead DEBUG_KMEM_UNIMPLEMENTED code was removed to clean things up and make the kmem.h a little more readable.
2010-06-12 01:48:18 +04:00
])
Linux 2.6.35 compat: filp_fsync() dropped 'stuct dentry *' The prototype for filp_fsync() drop the unused argument 'stuct dentry *'. I've fixed this by adding the needed autoconf check and moving all of those filp related functions to file_compat.h. This will simplify handling any further API changes in the future.
2010-07-14 22:26:54 +04:00
Linux 3.1 compat, vfs_fsync() Preferentially use the vfs_fsync() function. This function was initially introduced in 2.6.29 and took three arguments. As of 2.6.35 the dentry argument was dropped from the function. For older kernels fall back to using file_fsync() which also took three arguments including the dentry. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #52
2011-11-10 00:45:35 +04:00
dnl #
dnl # 2.6.29 API change,
dnl # vfs_fsync() funcation added, prior to this use file_fsync().
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_VFS_FSYNC],
[AC_MSG_CHECKING([whether vfs_fsync() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/fs.h>
], [
(void) vfs_fsync;
], [vfs_fsync], [fs/sync.c], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_VFS_FSYNC, 1, [vfs_fsync() is available])
], [
AC_MSG_RESULT(no)
])
Linux 3.1 compat, vfs_fsync() Preferentially use the vfs_fsync() function. This function was initially introduced in 2.6.29 and took three arguments. As of 2.6.35 the dentry argument was dropped from the function. For older kernels fall back to using file_fsync() which also took three arguments including the dentry. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #52
2011-11-10 00:45:35 +04:00
])
Linux 2.6.35 compat: filp_fsync() dropped 'stuct dentry *' The prototype for filp_fsync() drop the unused argument 'stuct dentry *'. I've fixed this by adding the needed autoconf check and moving all of those filp related functions to file_compat.h. This will simplify handling any further API changes in the future.
2010-07-14 22:26:54 +04:00
dnl #
dnl # 2.6.35 API change,
Linux 3.1 compat, vfs_fsync() Preferentially use the vfs_fsync() function. This function was initially introduced in 2.6.29 and took three arguments. As of 2.6.35 the dentry argument was dropped from the function. For older kernels fall back to using file_fsync() which also took three arguments including the dentry. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #52
2011-11-10 00:45:35 +04:00
dnl # Unused 'struct dentry *' removed from vfs_fsync() prototype.
Linux 2.6.35 compat: filp_fsync() dropped 'stuct dentry *' The prototype for filp_fsync() drop the unused argument 'stuct dentry *'. I've fixed this by adding the needed autoconf check and moving all of those filp related functions to file_compat.h. This will simplify handling any further API changes in the future.
2010-07-14 22:26:54 +04:00
dnl #
Linux 3.1 compat, vfs_fsync() Preferentially use the vfs_fsync() function. This function was initially introduced in 2.6.29 and took three arguments. As of 2.6.35 the dentry argument was dropped from the function. For older kernels fall back to using file_fsync() which also took three arguments including the dentry. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #52
2011-11-10 00:45:35 +04:00
AC_DEFUN([SPL_AC_2ARGS_VFS_FSYNC], [
AC_MSG_CHECKING([whether vfs_fsync() wants 2 args])
Linux 2.6.35 compat: filp_fsync() dropped 'stuct dentry *' The prototype for filp_fsync() drop the unused argument 'stuct dentry *'. I've fixed this by adding the needed autoconf check and moving all of those filp related functions to file_compat.h. This will simplify handling any further API changes in the future.
2010-07-14 22:26:54 +04:00
SPL_LINUX_TRY_COMPILE([
Linux 3.1 compat, vfs_fsync() Preferentially use the vfs_fsync() function. This function was initially introduced in 2.6.29 and took three arguments. As of 2.6.35 the dentry argument was dropped from the function. For older kernels fall back to using file_fsync() which also took three arguments including the dentry. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #52
2011-11-10 00:45:35 +04:00
#include <linux/fs.h>
Linux 2.6.35 compat: filp_fsync() dropped 'stuct dentry *' The prototype for filp_fsync() drop the unused argument 'stuct dentry *'. I've fixed this by adding the needed autoconf check and moving all of those filp related functions to file_compat.h. This will simplify handling any further API changes in the future.
2010-07-14 22:26:54 +04:00
],[
Linux 3.1 compat, vfs_fsync() Preferentially use the vfs_fsync() function. This function was initially introduced in 2.6.29 and took three arguments. As of 2.6.35 the dentry argument was dropped from the function. For older kernels fall back to using file_fsync() which also took three arguments including the dentry. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #52
2011-11-10 00:45:35 +04:00
vfs_fsync(NULL, 0);
Linux 2.6.35 compat: filp_fsync() dropped 'stuct dentry *' The prototype for filp_fsync() drop the unused argument 'stuct dentry *'. I've fixed this by adding the needed autoconf check and moving all of those filp related functions to file_compat.h. This will simplify handling any further API changes in the future.
2010-07-14 22:26:54 +04:00
],[
AC_MSG_RESULT(yes)
Linux 3.1 compat, vfs_fsync() Preferentially use the vfs_fsync() function. This function was initially introduced in 2.6.29 and took three arguments. As of 2.6.35 the dentry argument was dropped from the function. For older kernels fall back to using file_fsync() which also took three arguments including the dentry. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #52
2011-11-10 00:45:35 +04:00
AC_DEFINE(HAVE_2ARGS_VFS_FSYNC, 1, [vfs_fsync() wants 2 args])
Linux 2.6.35 compat: filp_fsync() dropped 'stuct dentry *' The prototype for filp_fsync() drop the unused argument 'stuct dentry *'. I've fixed this by adding the needed autoconf check and moving all of those filp related functions to file_compat.h. This will simplify handling any further API changes in the future.
2010-07-14 22:26:54 +04:00
],[
AC_MSG_RESULT(no)
])
])
Correctly handle rwsem_is_locked() behavior A race condition in rwsem_is_locked() was fixed in Linux 2.6.33 and the fix was backported to RHEL5 as of kernel 2.6.18-190.el5. Details can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=526092 The race condition was fixed in the kernel by acquiring the semaphore's wait_lock inside rwsem_is_locked(). The SPL worked around the race condition by acquiring the wait_lock before calling that function, but with the fix in place it must not do that. This commit implements an autoconf test to detect whether the fixed version of rwsem_is_locked() is present. The previous version of rwsem_is_locked() was an inline static function while the new version is exported as a symbol which we can check for in module.symvers. Depending on the result we correctly implement the needed compatibility macros for proper spinlock handling. Finally, we do the right thing with spin locks in RW_*_HELD() by using the new compatibility macros. We only only acquire the semaphore's wait_lock if it is calling a rwsem_is_locked() that does not itself try to acquire the lock. Some new overhead and a small harmless race is introduced by this change. This is because RW_READ_HELD() and RW_WRITE_HELD() now acquire and release the wait_lock twice: once for the call to rwsem_is_locked() and once for the call to rw_owner(). This can't be avoided if calling a rwsem_is_locked() that takes the wait_lock, as it will in more recent kernels. The other case which only occurs in legacy kernels could be optimized by taking the lock only once, as was done prior to this commit. However, I decided that the performance gain probably wasn't significant enough to justify the messy special cases required. The function spl_rw_get_owner() was only used to enable the afore-mentioned optimization. Since it is no longer used, I removed it. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2010-08-10 22:01:46 +04:00
Add interface for file hole punching. This adds an interface to "punch holes" (deallocate space) in VFS files. The interface is identical to the Solaris VOP_SPACE interface. This interface is necessary for TRIM support on file vdevs. This is implemented using Linux fallocate(FALLOC_FL_PUNCH_HOLE), which was introduced in 2.6.38. For a brief time before 2.6.38 this was done using the truncate_range inode operation, which was quickly deprecated. This patch only supports FALLOC_FL_PUNCH_HOLE. This adds support for the truncate_range() inode operation to VOP_SPACE() for file hole punching. This API is deprecated and removed in 3.5, so it's only useful for old kernels. On tmpfs, the truncate_range() inode operation translates to shmem_truncate_range(). Unfortunately, this function expects the end offset to be inclusive and aligned to the end of a page. If it is not, the kernel will stop with a BUG_ON(). This patch fixes the issue by adapting to the constraints set forth by shmem_truncate_range(). Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #168
2012-09-03 16:56:26 +04:00
dnl #
dnl # 3.5 API change,
dnl # inode_operations.truncate_range removed
dnl #
AC_DEFUN([SPL_AC_INODE_TRUNCATE_RANGE], [
AC_MSG_CHECKING([whether truncate_range() inode operation is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
struct inode_operations ops;
ops.truncate_range = NULL;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_INODE_TRUNCATE_RANGE, 1,
[truncate_range() inode operation is available])
],[
AC_MSG_RESULT(no)
])
RHEL 6.4 compat, fallocate() In the upstream kernel the FALLOC_FL_PUNCH_HOLE #define was introduced after the fallocate() function was moved from the inode_operations to the file_operations structure. Therefore, the SPL code assumed that if FALLOC_FL_PUNCH_HOLE was defined it was safe to use f_ops->fallocate(). Unfortunately, the RHEL6.4 kernel has only backported the FALLOC_FL_PUNCH_HOLE #define and not the fallocate() change. To address this compatibility issue the spl_filp_fallocate() helper function was added to properly detect which interface is available. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-01-08 21:42:49 +04:00
])
dnl #
dnl # Linux 2.6.38 - 3.x API
dnl #
AC_DEFUN([SPL_AC_KERNEL_FILE_FALLOCATE], [
AC_MSG_CHECKING([whether fops->fallocate() exists])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
long (*fallocate) (struct file *, int, loff_t, loff_t) = NULL;
struct file_operations fops __attribute__ ((unused)) = {
.fallocate = fallocate,
};
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_FILE_FALLOCATE, 1, [fops->fallocate() exists])
],[
AC_MSG_RESULT(no)
])
])
dnl #
dnl # Linux 2.6.x - 2.6.37 API
dnl #
AC_DEFUN([SPL_AC_KERNEL_INODE_FALLOCATE], [
AC_MSG_CHECKING([whether iops->fallocate() exists])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
long (*fallocate) (struct inode *, int, loff_t, loff_t) = NULL;
struct inode_operations fops __attribute__ ((unused)) = {
.fallocate = fallocate,
};
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_INODE_FALLOCATE, 1, [fops->fallocate() exists])
],[
AC_MSG_RESULT(no)
])
])
dnl #
dnl # PaX Linux 2.6.38 - 3.x API
dnl #
AC_DEFUN([SPL_AC_PAX_KERNEL_FILE_FALLOCATE], [
AC_MSG_CHECKING([whether fops->fallocate() exists])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
long (*fallocate) (struct file *, int, loff_t, loff_t) = NULL;
struct file_operations_no_const fops __attribute__ ((unused)) = {
.fallocate = fallocate,
};
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_FILE_FALLOCATE, 1, [fops->fallocate() exists])
],[
AC_MSG_RESULT(no)
])
])
dnl #
dnl # The fallocate callback was moved from the inode_operations
dnl # structure to the file_operations structure.
dnl #
AC_DEFUN([SPL_AC_KERNEL_FALLOCATE], [
SPL_AC_KERNEL_FILE_FALLOCATE
SPL_AC_KERNEL_INODE_FALLOCATE
SPL_AC_PAX_KERNEL_FILE_FALLOCATE
])
Add interface for file hole punching. This adds an interface to "punch holes" (deallocate space) in VFS files. The interface is identical to the Solaris VOP_SPACE interface. This interface is necessary for TRIM support on file vdevs. This is implemented using Linux fallocate(FALLOC_FL_PUNCH_HOLE), which was introduced in 2.6.38. For a brief time before 2.6.38 this was done using the truncate_range inode operation, which was quickly deprecated. This patch only supports FALLOC_FL_PUNCH_HOLE. This adds support for the truncate_range() inode operation to VOP_SPACE() for file hole punching. This API is deprecated and removed in 3.5, so it's only useful for old kernels. On tmpfs, the truncate_range() inode operation translates to shmem_truncate_range(). Unfortunately, this function expects the end offset to be inclusive and aligned to the end of a page. If it is not, the kernel will stop with a BUG_ON(). This patch fixes the issue by adapting to the constraints set forth by shmem_truncate_range(). Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #168
2012-09-03 16:56:26 +04:00
Correctly handle rwsem_is_locked() behavior A race condition in rwsem_is_locked() was fixed in Linux 2.6.33 and the fix was backported to RHEL5 as of kernel 2.6.18-190.el5. Details can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=526092 The race condition was fixed in the kernel by acquiring the semaphore's wait_lock inside rwsem_is_locked(). The SPL worked around the race condition by acquiring the wait_lock before calling that function, but with the fix in place it must not do that. This commit implements an autoconf test to detect whether the fixed version of rwsem_is_locked() is present. The previous version of rwsem_is_locked() was an inline static function while the new version is exported as a symbol which we can check for in module.symvers. Depending on the result we correctly implement the needed compatibility macros for proper spinlock handling. Finally, we do the right thing with spin locks in RW_*_HELD() by using the new compatibility macros. We only only acquire the semaphore's wait_lock if it is calling a rwsem_is_locked() that does not itself try to acquire the lock. Some new overhead and a small harmless race is introduced by this change. This is because RW_READ_HELD() and RW_WRITE_HELD() now acquire and release the wait_lock twice: once for the call to rwsem_is_locked() and once for the call to rw_owner(). This can't be avoided if calling a rwsem_is_locked() that takes the wait_lock, as it will in more recent kernels. The other case which only occurs in legacy kernels could be optimized by taking the lock only once, as was done prior to this commit. However, I decided that the performance gain probably wasn't significant enough to justify the messy special cases required. The function spl_rw_get_owner() was only used to enable the afore-mentioned optimization. Since it is no longer used, I removed it. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2010-08-10 22:01:46 +04:00
dnl #
dnl # 2.6.33 API change. Also backported in RHEL5 as of 2.6.18-190.el5.
dnl # Earlier versions of rwsem_is_locked() were inline and had a race
dnl # condition. The fixed version is exported as a symbol. The race
dnl # condition is fixed by acquiring sem->wait_lock, so we must not
dnl # call that version while holding sem->wait_lock.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_EXPORTED_RWSEM_IS_LOCKED],
[AC_MSG_CHECKING([whether rwsem_is_locked() acquires sem->wait_lock])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/rwsem.h>
int rwsem_is_locked(struct rw_semaphore *sem) { return 0; }
], [], [rwsem_is_locked], [lib/rwsem-spinlock.c], [
AC_MSG_RESULT(yes)
AC_DEFINE(RWSEM_IS_LOCKED_TAKES_WAIT_LOCK, 1,
[rwsem_is_locked() acquires sem->wait_lock])
], [
AC_MSG_RESULT(no)
])
Correctly handle rwsem_is_locked() behavior A race condition in rwsem_is_locked() was fixed in Linux 2.6.33 and the fix was backported to RHEL5 as of kernel 2.6.18-190.el5. Details can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=526092 The race condition was fixed in the kernel by acquiring the semaphore's wait_lock inside rwsem_is_locked(). The SPL worked around the race condition by acquiring the wait_lock before calling that function, but with the fix in place it must not do that. This commit implements an autoconf test to detect whether the fixed version of rwsem_is_locked() is present. The previous version of rwsem_is_locked() was an inline static function while the new version is exported as a symbol which we can check for in module.symvers. Depending on the result we correctly implement the needed compatibility macros for proper spinlock handling. Finally, we do the right thing with spin locks in RW_*_HELD() by using the new compatibility macros. We only only acquire the semaphore's wait_lock if it is calling a rwsem_is_locked() that does not itself try to acquire the lock. Some new overhead and a small harmless race is introduced by this change. This is because RW_READ_HELD() and RW_WRITE_HELD() now acquire and release the wait_lock twice: once for the call to rwsem_is_locked() and once for the call to rw_owner(). This can't be avoided if calling a rwsem_is_locked() that takes the wait_lock, as it will in more recent kernels. The other case which only occurs in legacy kernels could be optimized by taking the lock only once, as was done prior to this commit. However, I decided that the performance gain probably wasn't significant enough to justify the messy special cases required. The function spl_rw_get_owner() was only used to enable the afore-mentioned optimization. Since it is no longer used, I removed it. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2010-08-10 22:01:46 +04:00
])
Linux compat 2.6.37, invalidate_inodes() In the 2.6.37 kernel the function invalidate_inodes() is no longer exported for use by modules. This memory management functionality is needed to invalidate the inodes attached to a super block without unmounting the filesystem. Because this function still exists in the kernel and the prototype is available is a common header all we strictly need is the symbol address. The address is obtained using spl_kallsyms_lookup_name() and assigned to the variable invalidate_inodes_fn. Then a #define is used to replace all instances of invalidate_inodes() with a call to the acquired address. All the complexity is hidden behind HAVE_INVALIDATE_INODES and invalidate_inodes() can be used as usual. Long term we should try to get this, or another, interface made available to modules again.
2011-02-23 23:25:45 +03:00
Add dnlc_reduce_cache() support Provide the dnlc_reduce_cache() function which attempts to prune cached entries from the dcache and icache. After the entries are pruned any slabs which they may have been using are reaped. Note the API takes a reclaim percentage but we don't have easy access to the total number of cache entries to calculate the reclaim count. However, in practice this doesn't need to be exactly correct. We simply need to reclaim some useful fraction (but not all) of the cache. The caller can determine if more needs to be done.
2011-03-31 04:44:35 +04:00
dnl #
dnl # 2.6.xx API compat,
dnl # There currently exists no exposed API to partially shrink the dcache.
dnl # The expected mechanism to shrink the cache is a registered shrinker
dnl # which is called during memory pressure.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_SHRINK_DCACHE_MEMORY],
[AC_MSG_CHECKING([whether shrink_dcache_memory() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/dcache.h>
], [
shrink_dcache_memory(0, 0);
], [shrink_dcache_memory], [fs/dcache.c], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_SHRINK_DCACHE_MEMORY, 1,
[shrink_dcache_memory() is available])
], [
AC_MSG_RESULT(no)
])
Add dnlc_reduce_cache() support Provide the dnlc_reduce_cache() function which attempts to prune cached entries from the dcache and icache. After the entries are pruned any slabs which they may have been using are reaped. Note the API takes a reclaim percentage but we don't have easy access to the total number of cache entries to calculate the reclaim count. However, in practice this doesn't need to be exactly correct. We simply need to reclaim some useful fraction (but not all) of the cache. The caller can determine if more needs to be done.
2011-03-31 04:44:35 +04:00
])
dnl #
dnl # 2.6.xx API compat,
dnl # There currently exists no exposed API to partially shrink the icache.
dnl # The expected mechanism to shrink the cache is a registered shrinker
dnl # which is called during memory pressure.
dnl #
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_DEFUN([SPL_AC_SHRINK_ICACHE_MEMORY],
[AC_MSG_CHECKING([whether shrink_icache_memory() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/dcache.h>
], [
shrink_icache_memory(0, 0);
], [shrink_icache_memory], [fs/inode.c], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_SHRINK_ICACHE_MEMORY, 1,
[shrink_icache_memory() is available])
], [
AC_MSG_RESULT(no)
])
Add dnlc_reduce_cache() support Provide the dnlc_reduce_cache() function which attempts to prune cached entries from the dcache and icache. After the entries are pruned any slabs which they may have been using are reaped. Note the API takes a reclaim percentage but we don't have easy access to the total number of cache entries to calculate the reclaim count. However, in practice this doesn't need to be exactly correct. We simply need to reclaim some useful fraction (but not all) of the cache. The caller can determine if more needs to be done.
2011-03-31 04:44:35 +04:00
])
Linux 2.6.39 compat, kern_path_parent() The path_lookup() function has been renamed to kern_path_parent() and the flags argument has been removed. The only behavior now offered is that of LOOKUP_PARENT. The spl already always passed this flag so dropping the flag does not impact us.
2011-04-20 23:25:59 +04:00
dnl #
Cleanup vn_rename() and vn_remove() zfsonlinux/spl#bcb15891ab394e11615eee08bba1fd85ac32e158 implemented Linux 3.6+ support by adding duplicate vn_rename and vn_remove functions. The new ones were cleaner, but the duplicate functions made the codebase less maintainable. This adds some compatibility shims that allow us to retire the older vn_rename and vn_remove in favor of the new ones on old kernels. The result is a net 143 line reduction in lines of code and a cleaner codebase. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #370
2014-06-29 09:00:02 +04:00
dnl # 2.6.28 API change
dnl # The kern_path() function has been introduced. We adopt it as the new way
dnl # of looking up paths. When it is not available, we emulate it using the
dnl # older interfaces.
Linux 2.6.39 compat, kern_path_parent() The path_lookup() function has been renamed to kern_path_parent() and the flags argument has been removed. The only behavior now offered is that of LOOKUP_PARENT. The spl already always passed this flag so dropping the flag does not impact us.
2011-04-20 23:25:59 +04:00
dnl #
Cleanup vn_rename() and vn_remove() zfsonlinux/spl#bcb15891ab394e11615eee08bba1fd85ac32e158 implemented Linux 3.6+ support by adding duplicate vn_rename and vn_remove functions. The new ones were cleaner, but the duplicate functions made the codebase less maintainable. This adds some compatibility shims that allow us to retire the older vn_rename and vn_remove in favor of the new ones on old kernels. The result is a net 143 line reduction in lines of code and a cleaner codebase. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #370
2014-06-29 09:00:02 +04:00
AC_DEFUN([SPL_AC_KERN_PATH],
[AC_MSG_CHECKING([whether kern_path() is available])
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/namei.h>
], [
Cleanup vn_rename() and vn_remove() zfsonlinux/spl#bcb15891ab394e11615eee08bba1fd85ac32e158 implemented Linux 3.6+ support by adding duplicate vn_rename and vn_remove functions. The new ones were cleaner, but the duplicate functions made the codebase less maintainable. This adds some compatibility shims that allow us to retire the older vn_rename and vn_remove in favor of the new ones on old kernels. The result is a net 143 line reduction in lines of code and a cleaner codebase. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #370
2014-06-29 09:00:02 +04:00
int r = kern_path(NULL, 0, NULL);
], [kern_path], [fs/namei.c], [
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
AC_MSG_RESULT(yes)
Cleanup vn_rename() and vn_remove() zfsonlinux/spl#bcb15891ab394e11615eee08bba1fd85ac32e158 implemented Linux 3.6+ support by adding duplicate vn_rename and vn_remove functions. The new ones were cleaner, but the duplicate functions made the codebase less maintainable. This adds some compatibility shims that allow us to retire the older vn_rename and vn_remove in favor of the new ones on old kernels. The result is a net 143 line reduction in lines of code and a cleaner codebase. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #370
2014-06-29 09:00:02 +04:00
AC_DEFINE(HAVE_KERN_PATH, 1,
[kern_path() is available])
When checking for symbol exports, try compiling. This patch adds a new autoconf function: SPL_LINUX_TRY_COMPILE_SYMBOL. This new function does the following: - Call LINUX_TRY_COMPILE with the specified parameters. - If unsuccessful, return false. - If successful and we're configuring with --enable-linux-builtin, return true. - Else, call CHECK_SYMBOL_EXPORT with the specified parameters and return the result. All calls to CHECK_SYMBOL_EXPORT are converted to LINUX_TRY_COMPILE_SYMBOL so that the tests work even when configuring for builtin on a kernel which doesn't have loadable module support, or hasn't been built yet. The only exception are: - AC_GET_VMALLOC_INFO, because we don't even have a public header to include in the test case, but that's okay considering this symbol can be ignored just fine. - SPL_AC_DEVICE_CREATE, which is legacy API for 2.6.18 kernels. Since kernels this old are no longer supported it should arguably just be removed entirely from the build system. Note that we're also checking for the correct prototype with an actual call, which was not the case with CHECK_SYMBOL_EXPORT. However, for "complicated" test cases like with multiple symbol versions (e.g. vfs_fsync), we stick with the original behavior and only check for the function's existence. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue zfsonlinux/zfs#851
2012-07-16 19:04:05 +04:00
], [
AC_MSG_RESULT(no)
Cleanup vn_rename() and vn_remove() zfsonlinux/spl#bcb15891ab394e11615eee08bba1fd85ac32e158 implemented Linux 3.6+ support by adding duplicate vn_rename and vn_remove functions. The new ones were cleaner, but the duplicate functions made the codebase less maintainable. This adds some compatibility shims that allow us to retire the older vn_rename and vn_remove in favor of the new ones on old kernels. The result is a net 143 line reduction in lines of code and a cleaner codebase. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #370
2014-06-29 09:00:02 +04:00
AC_MSG_CHECKING([whether path_lookup() is available])
SPL_LINUX_TRY_COMPILE_SYMBOL([
#include <linux/namei.h>
], [
int r = path_lookup(NULL, 0, NULL);
], [path_lookup], [fs/namei.c], [
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_KERN_PATH, 1,
[kern_path() is available])
], [
AC_MSG_RESULT(no)
AC_MSG_ERROR([
*** Neither kern_path() nor path_lookup() is available.
*** Please file an issue:
*** https://github.com/zfsonlinux/spl/issues/new])
Linux 2.6.39 compat, zlib_deflate_workspacesize() The function zlib_deflate_workspacesize() now take 2 arguments. This was done to avoid always having to allocate the maximum size workspace (268K). The caller can now specific the windowBits and memLevel compression parameters to get a smaller workspace. For our purposes we introduce a spl_zlib_deflate_workspacesize() wrapper which accepts both arguments. When the two argument version of zlib_deflate_workspacesize() is available the arguments are passed through. When it's not we assume the worst case and a maximally sized workspace is used.
2011-04-21 01:22:35 +04:00
Cleanup vn_rename() and vn_remove() zfsonlinux/spl#bcb15891ab394e11615eee08bba1fd85ac32e158 implemented Linux 3.6+ support by adding duplicate vn_rename and vn_remove functions. The new ones were cleaner, but the duplicate functions made the codebase less maintainable. This adds some compatibility shims that allow us to retire the older vn_rename and vn_remove in favor of the new ones on old kernels. The result is a net 143 line reduction in lines of code and a cleaner codebase. Signed-off-by: Richard Yao <ryao@gentoo.org> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #370
2014-06-29 09:00:02 +04:00
])
])
Linux 3.6 compat, kern_path_locked() added The kern_path_parent() function was removed from Linux 3.6 because it was observed that all the callers just want the parent dentry. The simpler kern_path_locked() function replaces kern_path_parent() and does the lookup while holding the ->i_mutex lock. This is good news for the vn implementation because it removes the need for us to handle the locking. However, it makes it harder to implement a single readable vn_remove()/vn_rename() function which is usually what we prefer. Therefore, we implement a new version of vn_remove()/vn_rename() for Linux 3.6 and newer kernels. This allows us to leave the existing working implementation untouched, and to add a simpler version for newer kernels. Long term I would very much like to see all of the vn code removed since what this code enabled is generally frowned upon in the kernel. But that can't happen util we either abondon the zpool.cache file or implement alternate infrastructure to update is correctly in user space. Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com> Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #154
2012-10-11 18:41:33 +04:00
])
Check for KALLSYMS Check at ./configure time that the kernel was built with kallsyms support. If the kernel doesn't have CONFIG_KALLSYMS defined the modules will still compile cleanly but will not be loadable. So we really want to catch this early during ./configure. Note that we do not require CONFIG_KALLSYMS_ALL but it may be safely defined. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #6
2013-01-30 04:13:07 +04:00
dnl #
dnl # /proc/kallsyms support,
dnl # Verify the kernel has CONFIG_KALLSYMS support enabled.
dnl #
AC_DEFUN([SPL_AC_CONFIG_KALLSYMS], [
AC_MSG_CHECKING([whether CONFIG_KALLSYMS is defined])
SPL_LINUX_TRY_COMPILE([
#if !defined(CONFIG_KALLSYMS)
#error CONFIG_KALLSYMS not defined
#endif
],[ ],[
AC_MSG_RESULT([yes])
],[
AC_MSG_RESULT([no])
AC_MSG_ERROR([
*** This kernel does not include the required kallsyms support.
*** Rebuild the kernel with CONFIG_KALLSYMS=y set.])
])
])
Check for ZLIB_INFLATE and ZLIB_DEFLATE Check at ./configure time that the kernel was built with zlib support enabled. This support may either be configured as a module or builtin to the kernel. But if it's missing the build will fail so it's best to catch this early. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes zfsonlinux/zfs#582
2013-01-10 03:26:46 +04:00
dnl #
dnl # zlib inflate compat,
dnl # Verify the kernel has CONFIG_ZLIB_INFLATE support enabled.
dnl #
AC_DEFUN([SPL_AC_CONFIG_ZLIB_INFLATE], [
AC_MSG_CHECKING([whether CONFIG_ZLIB_INFLATE is defined])
SPL_LINUX_TRY_COMPILE([
#if !defined(CONFIG_ZLIB_INFLATE) && \
!defined(CONFIG_ZLIB_INFLATE_MODULE)
#error CONFIG_ZLIB_INFLATE not defined
#endif
],[ ],[
AC_MSG_RESULT([yes])
],[
AC_MSG_RESULT([no])
AC_MSG_ERROR([
*** This kernel does not include the required zlib inflate support.
*** Rebuild the kernel with CONFIG_ZLIB_INFLATE=y|m set.])
])
])
dnl #
dnl # zlib deflate compat,
dnl # Verify the kernel has CONFIG_ZLIB_DEFLATE support enabled.
dnl #
AC_DEFUN([SPL_AC_CONFIG_ZLIB_DEFLATE], [
AC_MSG_CHECKING([whether CONFIG_ZLIB_DEFLATE is defined])
SPL_LINUX_TRY_COMPILE([
#if !defined(CONFIG_ZLIB_DEFLATE) && \
!defined(CONFIG_ZLIB_DEFLATE_MODULE)
#error CONFIG_ZLIB_DEFLATE not defined
#endif
],[ ],[
AC_MSG_RESULT([yes])
],[
AC_MSG_RESULT([no])
AC_MSG_ERROR([
*** This kernel does not include the required zlib deflate support.
*** Rebuild the kernel with CONFIG_ZLIB_DEFLATE=y|m set.])
])
])
Linux 2.6.39 compat, zlib_deflate_workspacesize() The function zlib_deflate_workspacesize() now take 2 arguments. This was done to avoid always having to allocate the maximum size workspace (268K). The caller can now specific the windowBits and memLevel compression parameters to get a smaller workspace. For our purposes we introduce a spl_zlib_deflate_workspacesize() wrapper which accepts both arguments. When the two argument version of zlib_deflate_workspacesize() is available the arguments are passed through. When it's not we assume the worst case and a maximally sized workspace is used.
2011-04-21 01:22:35 +04:00
dnl #
dnl # 2.6.39 API compat,
dnl # The function zlib_deflate_workspacesize() now take 2 arguments.
dnl # This was done to avoid always having to allocate the maximum size
dnl # workspace (268K). The caller can now specific the windowBits and
dnl # memLevel compression parameters to get a smaller workspace.
dnl #
AC_DEFUN([SPL_AC_2ARGS_ZLIB_DEFLATE_WORKSPACESIZE],
[AC_MSG_CHECKING([whether zlib_deflate_workspacesize() wants 2 args])
SPL_LINUX_TRY_COMPILE([
#include <linux/zlib.h>
],[
return zlib_deflate_workspacesize(MAX_WBITS, MAX_MEM_LEVEL);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_2ARGS_ZLIB_DEFLATE_WORKSPACESIZE, 1,
[zlib_deflate_workspacesize() wants 2 args])
],[
AC_MSG_RESULT(no)
])
])
Linux 3.0: Shrinker compatibility Update the the wrapper macros for the memory shrinker to handle this 4th API change. The callback function now takes a shrink_control structure. This is certainly a step in the right direction but it's annoying to have to accomidate yet another version of the API.
2011-06-17 02:39:08 +04:00
dnl #
dnl # 2.6.39 API change,
dnl # Shrinker adjust to use common shrink_control structure.
dnl #
AC_DEFUN([SPL_AC_SHRINK_CONTROL_STRUCT], [
AC_MSG_CHECKING([whether struct shrink_control exists])
SPL_LINUX_TRY_COMPILE([
#include <linux/mm.h>
],[
struct shrink_control sc __attribute__ ((unused));
sc.nr_to_scan = 0;
sc.gfp_mask = GFP_KERNEL;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_SHRINK_CONTROL_STRUCT, 1,
[struct shrink_control exists])
],[
AC_MSG_RESULT(no)
])
])
Linux 3.2 compat: rw_semaphore.wait_lock is raw The wait_lock member of the rw_semaphore struct became a raw_spinlock_t in Linux 3.2 at torvalds/linux@ddb6c9b58a19edcfac93ac670b066c836ff729f1. Wrap spin_lock_* function calls in a new spl_rwsem_* interface to ensure type safety if raw_spinlock_t becomes architecture specific, and to satisfy these compiler warnings: warning: passing argument 1 of ‘spinlock_check’ from incompatible pointer type [enabled by default] note: expected ‘struct spinlock_t *’ but argument is of type ‘struct raw_spinlock_t *’ Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes: #76 Closes: zfsonlinux/zfs#463
2012-01-11 21:44:34 +04:00
dnl #
dnl # 3.1 API Change
dnl #
dnl # The rw_semaphore.wait_lock member was changed from spinlock_t to
dnl # raw_spinlock_t at commit ddb6c9b58a19edcfac93ac670b066c836ff729f1.
dnl #
AC_DEFUN([SPL_AC_RWSEM_SPINLOCK_IS_RAW], [
AC_MSG_CHECKING([whether struct rw_semaphore member wait_lock is raw])
tmp_flags="$EXTRA_KCFLAGS"
EXTRA_KCFLAGS="-Werror"
SPL_LINUX_TRY_COMPILE([
#include <linux/rwsem.h>
],[
struct rw_semaphore dummy_semaphore __attribute__ ((unused));
raw_spinlock_t dummy_lock __attribute__ ((unused));
dummy_semaphore.wait_lock = dummy_lock;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(RWSEM_SPINLOCK_IS_RAW, 1,
[struct rw_semaphore member wait_lock is raw_spinlock_t])
],[
AC_MSG_RESULT(no)
])
EXTRA_KCFLAGS="$tmp_flags"
])
Linux 3.9 compat: Include linux/sched/rt.h Linux 3.9 reorganized sched.h, splitting it into numerous files. torvalds/linux@8bd75c77b7c6a3954140dd2e20346aef3efe4a35 moved MAX_PRIO and MAX_RT_PRIO to linux/sched/rt.h. Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-03-04 08:42:32 +04:00
dnl #
dnl # 3.9 API change,
dnl # Moved things from linux/sched.h to linux/sched/rt.h
dnl #
AC_DEFUN([SPL_AC_SCHED_RT_HEADER],
[AC_MSG_CHECKING([whether header linux/sched/rt.h exists])
SPL_LINUX_TRY_COMPILE([
#include <linux/sched.h>
#include <linux/sched/rt.h>
],[
return 0;
],[
AC_DEFINE(HAVE_SCHED_RT_HEADER, 1, [linux/sched/rt.h exists])
AC_MSG_RESULT(yes)
],[
AC_MSG_RESULT(no)
])
])
Linux 3.9 compat: vfs_getattr takes two arguments The function prototype of vfs_getattr previoulsy took struct vfsmount * and struct dentry * as arguments. These would always be defined together in a struct path *. torvalds/linux@3dadecce20603aa380023c65e6f55f108fd5e952 modified vfs_getattr to take struct path * is taken as an argument instead. Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2013-03-04 09:02:43 +04:00
dnl #
dnl # 3.9 API change,
dnl # vfs_getattr() uses 2 args
dnl # It takes struct path * instead of struct vfsmount * and struct dentry *
dnl #
AC_DEFUN([SPL_AC_2ARGS_VFS_GETATTR], [
AC_MSG_CHECKING([whether vfs_getattr() wants])
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
vfs_getattr((struct path *) NULL,
(struct kstat *)NULL);
],[
AC_MSG_RESULT(2 args)
AC_DEFINE(HAVE_2ARGS_VFS_GETATTR, 1,
[vfs_getattr wants 2 args])
],[
SPL_LINUX_TRY_COMPILE([
#include <linux/fs.h>
],[
vfs_getattr((struct vfsmount *)NULL,
(struct dentry *)NULL,
(struct kstat *)NULL);
],[
AC_MSG_RESULT(3 args)
],[
AC_MSG_ERROR(unknown)
])
])
])
Emulate illumos interface cv_timedwait_hires() Needed for Illumos #3582. This interface is supposed to support a variable-resolution timeout with nanosecond granularity. This implementation rounds up to microsecond resolution, as nanosecond- precision timing is rarely needed for real-world performance tuning and may incur unnecessary busy-waiting. usleep_range() is used if available, otherwise udelay() or msleep() are used depending on the length of the delay interval. Add flags from sys/callo.h as these are used to control the behavior of cv_timedwait_hires(). Specifically, CALLOUT_FLAG_ABSOLUTE Normally, the expiration passed to the timeout API functions is an expiration interval. If this flag is specified, then it is interpreted as the expiration time itself. CALLOUT_FLAG_ROUNDUP Roundup the expiration time to the next resolution boundary. If this flag is not specified, the expiration time is rounded down. References: https://www.illumos.org/issues/3582 illumos/illumos-gate@0689f76 Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #304
2013-11-02 00:37:58 +04:00
dnl #
dnl # 2.6.36 API compatibility.
dnl # Added usleep_range timer.
dnl # usleep_range is a finer precision implementation of msleep
dnl # designed to be a drop-in replacement for udelay where a precise
dnl # sleep / busy-wait is unnecessary.
dnl #
AC_DEFUN([SPL_AC_USLEEP_RANGE], [
AC_MSG_CHECKING([whether usleep_range() is available])
SPL_LINUX_TRY_COMPILE([
#include <linux/delay.h>
],[
usleep_range(0, 0);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_USLEEP_RANGE, 1,
[usleep_range is available])
],[
AC_MSG_RESULT(no)
])
])
Add KMC_SLAB cache type For small objects the Linux slab allocator has several advantages over its counterpart in the SPL. These include: 1) It is more memory-efficient and packs objects more tightly. 2) It is continually tuned to maximize performance. Therefore it makes sense to layer the SPLs slab allocator on top of the Linux slab allocator. This allows us to leverage the advantages above while preserving the Illumos semantics we depend on. However, there are some things we need to be careful of: 1) The Linux slab allocator was never designed to work well with large objects. Because the SPL slab must still handle this use case a cut off limit was added to transition from Linux slab backed objects to kmem or vmem backed slabs. spl_kmem_cache_slab_limit - Objects less than or equal to this size in bytes will be backed by the Linux slab. By default this value is zero which disables the Linux slab functionality. Reasonable values for this cut off limit are in the range of 4096-16386 bytes. spl_kmem_cache_kmem_limit - Objects less than or equal to this size in bytes will be backed by a kmem slab. Objects over this size will be vmem backed instead. This value defaults to 1/8 a page, or 512 bytes on an x86_64 architecture. 2) Be aware that using the Linux slab may inadvertently introduce new deadlocks. Care has been taken previously to ensure that all allocations which occur in the write path use GFP_NOIO. However, there may be internal allocations performed in the Linux slab which do not honor these flags. If this is the case a deadlock may occur. The path forward is definitely to start relying on the Linux slab. But for that to happen we need to start building confidence that there aren't any unexpected surprises lurking for us. And ideally need to move completely away from using the SPLs slab for large memory allocations. This patch is a first step. NOTES: 1) The KMC_NOMAGAZINE flag was leveraged to support the Linux slab backed caches but it is not supported for kmem/vmem backed caches. 2) Regardless of the spl_kmem_cache_*_limit settings a cache may be explicitly set to a given type by passed the KMC_KMEM, KMC_VMEM, or KMC_SLAB flags during cache creation. 3) The constructors, destructors, and reclaim callbacks are all functional and will be called regardless of the cache type. 4) KMC_SLAB caches will not appear in /proc/spl/kmem/slab due to the issues involved in presenting correct object accounting. Instead they will appear in /proc/slabinfo under the same names. 5) Several kmem SPLAT tests needed to be fixed because they relied incorrectly on internal kmem slab accounting. With the updated test cases all the SPLAT tests pass as expected. 6) An autoconf test was added to ensure that the __GFP_COMP flag was correctly added to the default flags used when allocating a slab. This is required to ensure all pages in higher order slabs are properly refcounted, see ae16ed9. 7) When using the SLUB allocator there is no need to attempt to set the __GFP_COMP flag. This has been the default behavior for the SLUB since Linux 2.6.25. 8) When using the SLUB it may be desirable to set the slub_nomerge kernel parameter to prevent caches from being merged. Original-patch-by: DHE <git@dehacked.net> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Prakash Surya <surya1@llnl.gov> Signed-off-by: Tim Chase <tim@chase2k.com> Signed-off-by: DHE <git@dehacked.net> Signed-off-by: Chunwei Chen <tuxoko@gmail.com> Closes #356
2013-12-09 02:01:45 +04:00
dnl #
dnl # 2.6.35 API change,
dnl # The cachep->gfpflags member was renamed cachep->allocflags. These are
dnl # private allocation flags which are applied when allocating a new slab
dnl # in kmem_getpages(). Unfortunately there is no public API for setting
dnl # non-default flags.
dnl #
AC_DEFUN([SPL_AC_KMEM_CACHE_ALLOCFLAGS], [
AC_MSG_CHECKING([whether struct kmem_cache has allocflags])
SPL_LINUX_TRY_COMPILE([
#include <linux/slab.h>
],[
struct kmem_cache cachep __attribute__ ((unused));
cachep.allocflags = GFP_KERNEL;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_KMEM_CACHE_ALLOCFLAGS, 1,
[struct kmem_cache has allocflags])
],[
AC_MSG_RESULT(no)
AC_MSG_CHECKING([whether struct kmem_cache has gfpflags])
SPL_LINUX_TRY_COMPILE([
#include <linux/slab.h>
],[
struct kmem_cache cachep __attribute__ ((unused));
cachep.gfpflags = GFP_KERNEL;
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_KMEM_CACHE_GFPFLAGS, 1,
[struct kmem_cache has gfpflags])
],[
AC_MSG_RESULT(no)
])
])
])
Linux 3.17 compat: remove wait_on_bit action function Linux kernel 3.17 removes the action function argument from wait_on_bit(). Add autoconf test and compatibility macro to support the new interface. The former "wait_on_bit" interface required an 'action' function to be provided which does the actual waiting. There were over 20 such functions in the kernel, many of them identical, though most cases can be satisfied by one of just two functions: one which uses io_schedule() and one which just uses schedule(). This API change was made to consolidate all of those redundant wait functions. References: torvalds/linux@7431620 Signed-off-by: Ned Bass <bass6@llnl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #378
2014-08-09 04:41:22 +04:00
dnl #
dnl # 3.17 API change,
dnl # wait_on_bit() no longer requires an action argument. The former
dnl # "wait_on_bit" interface required an 'action' function to be provided
dnl # which does the actual waiting. There were over 20 such functions in the
dnl # kernel, many of them identical, though most cases can be satisfied by one
dnl # of just two functions: one which uses io_schedule() and one which just
dnl # uses schedule(). This API change was made to consolidate all of those
dnl # redundant wait functions.
dnl #
AC_DEFUN([SPL_AC_WAIT_ON_BIT], [
AC_MSG_CHECKING([whether wait_on_bit() takes an action])
SPL_LINUX_TRY_COMPILE([
#include <linux/wait.h>
],[
int (*action)(void *) = NULL;
wait_on_bit(NULL, 0, action, 0);
],[
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_WAIT_ON_BIT_ACTION, 1, [yes])
],[
AC_MSG_RESULT(no)
])
])
Reference in New Issue Copy Permalink