c/mirror_zfs
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_zfs.git synced 2024-11-18 10:21:01 +03:00
Code Issues Packages Projects Releases Wiki Activity
a196b3bc3d
mirror_zfs/include/linux/Makefile.am

27 lines
709 B
Makefile
Raw Normal View History

Add Linux Compat Infrastructure Lay the initial ground work for a include/linux/ compatibility directory. This was less critical in the past because the bulk of the ZFS code consumes the Solaris API via the SPL. This API was stable and the bulk Linux API differences were handled in the SPL. However, with the addition of a full Posix layer written directly against the Linux APIs we are going to need more compatibility code. It makes sense that all this code should be cleanly located in one place. Subsequent patches should move the existing zvol and vdev_disk compatibility code in to this directory.
2011-01-18 22:42:25 +03:00
COMMON_H =
KERNEL_H = \
Linux 2.6.35 compat, fops->fsync() The fsync() callback in the file_operations structure used to take 3 arguments. The callback now only takes 2 arguments because the dentry argument was determined to be unused by all consumers. To handle this a compatibility prototype was added to ensure the right prototype is used. Our implementation never used the dentry argument either so it's just a matter of using the right prototype.
2011-02-11 19:58:55 +03:00
$(top_srcdir)/include/linux/dcache_compat.h \
$(top_srcdir)/include/linux/xattr_compat.h \
Add the new blkdev_compat.h header to the DIST target. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2011-02-24 20:08:35 +03:00
$(top_srcdir)/include/linux/vfs_compat.h \
Update utsname support Modify the code to use the utsname() kernel function rather than a global variable. This results is cleaner more portable code because utsname() is already provided by the kernel and can be easily emulated in user space via uname(2). This means that it will behave consistently in both contexts. This is also has the benefit that it allows the removal of a few _KERNEL pre-processor conditions. And it also is a pre-requisite for a proper FUSE port because we need to provide a valid utsname. Finally, it allows us to remove this functionality from the SPL and all the related compatibility code. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #2757
2014-10-01 23:02:12 +04:00
$(top_srcdir)/include/linux/blkdev_compat.h \
Add compatibility layer for {kmap,kunmap}_atomic Starting from linux-2.6.37, {kmap,kunmap}_atomic takes 1 argument instead of 2. We use zfs_{kmap,kunmap}_atomic as wrappers and always take 2 argument, but ignore the 2nd for newer kernel. Signed-off-by: Chunwei Chen <tuxoko@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
2015-05-11 17:22:56 +03:00
$(top_srcdir)/include/linux/utsname_compat.h \
Support for vectorized algorithms on x86 This is initial support for x86 vectorized implementations of ZFS parity and checksum algorithms. For the compilation phase, configure step checks if toolchain supports relevant instruction sets. Each implementation must ensure that the code is not passed to compiler if relevant instruction set is not supported. For this purpose, following new defines are provided if instruction set is supported: - HAVE_SSE, - HAVE_SSE2, - HAVE_SSE3, - HAVE_SSSE3, - HAVE_SSE4_1, - HAVE_SSE4_2, - HAVE_AVX, - HAVE_AVX2. For detecting if an instruction set can be used in runtime, following functions are provided in (include/linux/simd_x86.h): - zfs_sse_available() - zfs_sse2_available() - zfs_sse3_available() - zfs_ssse3_available() - zfs_sse4_1_available() - zfs_sse4_2_available() - zfs_avx_available() - zfs_avx2_available() - zfs_bmi1_available() - zfs_bmi2_available() These function should be called once, on module load, or initialization. They are safe to use from user and kernel space. If an implementation is using more than single instruction set, both compiler and runtime support for all relevant instruction sets should be checked. Kernel fpu methods: - kfpu_begin() - kfpu_end() Use __get_cpuid_max and __cpuid_count from <cpuid.h> Both gcc and clang have support for these. They also handle ebx register in case it is used for PIC code. Signed-off-by: Gvozden Neskovic <neskovic@gmail.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Chunwei Chen <tuxoko@gmail.com> Closes #4381
2016-02-29 21:42:27 +03:00
$(top_srcdir)/include/linux/kmap_compat.h \
Linux compat: Grsecurity kernel API Change: Module parameter set/get methods take const parameter in Grsecurity kernel v4.7.1 Signed-off-by: Gvozden Neskovic <neskovic@gmail.com> Signed-off-by: Jason Zaman <jason@perfinion.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #4997 Closes #5001
2016-08-21 22:29:49 +03:00
$(top_srcdir)/include/linux/simd_x86.h \
Add parity generation/rebuild using 128-bits NEON for Aarch64 This re-use the framework established for SSE2, SSSE3 and AVX2. However, GCC is using FP registers on Aarch64, so unlike SSE/AVX2 we can't rely on the registers being left alone between ASM statements. So instead, the NEON code uses C variables and GCC extended ASM syntax. Note that since the kernel explicitly disable vector registers, they have to be locally re-enabled explicitly. As we use the variable's number to define the symbolic name, and GCC won't allow duplicate symbolic names, numbers have to be unique. Even when the code is not going to be used (e.g. the case for 4 registers when using the macro with only 2). Only the actually used variables should be declared, otherwise the build will fails in debug mode. This requires the replacement of the XOR(X,X) syntax by a new ZERO(X) macro, which does the same thing but without repeating the argument. And perhaps someday there will be a machine where there is a more efficient way to zero a register than XOR with itself. This affects scalar, SSE2, SSSE3 and AVX2 as they need the new macro. It's possible to write faster implementations (different scheduling, different unrolling, interleaving NEON and scalar, ...) for various cores, but this one has the advantage of fitting in the current state of the code, and thus is likely easier to review/check/merge. The only difference between aarch64-neon and aarch64-neonx2 is that aarch64-neonx2 unroll some functions some more. Reviewed-by: Gvozden Neskovic <neskovic@gmail.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Romain Dolbeau <romain.dolbeau@atos.net> Closes #4801
2016-10-03 19:44:00 +03:00
$(top_srcdir)/include/linux/simd_aarch64.h \
Linux compat: Grsecurity kernel API Change: Module parameter set/get methods take const parameter in Grsecurity kernel v4.7.1 Signed-off-by: Gvozden Neskovic <neskovic@gmail.com> Signed-off-by: Jason Zaman <jason@perfinion.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #4997 Closes #5001
2016-08-21 22:29:49 +03:00
$(top_srcdir)/include/linux/mod_compat.h
Add Linux Compat Infrastructure Lay the initial ground work for a include/linux/ compatibility directory. This was less critical in the past because the bulk of the ZFS code consumes the Solaris API via the SPL. This API was stable and the bulk Linux API differences were handled in the SPL. However, with the addition of a full Posix layer written directly against the Linux APIs we are going to need more compatibility code. It makes sense that all this code should be cleanly located in one place. Subsequent patches should move the existing zvol and vdev_disk compatibility code in to this directory.
2011-01-18 22:42:25 +03:00
USER_H =
EXTRA_DIST = $(COMMON_H) $(KERNEL_H) $(USER_H)
if CONFIG_USER
libzfsdir = $(includedir)/libzfs/linux
libzfs_HEADERS = $(COMMON_H) $(USER_H)
endif
if CONFIG_KERNEL
Kernel header installation should respect --prefix This is the upstream component of work that enables preliminary support for building Gentoo's ZFS packaging on other Linux systems via Gentoo Prefix. Signed-off-by: Richard Yao <richard.yao@clusterhq.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #2641
2014-08-29 19:53:09 +04:00
kerneldir = @prefix@/src/zfs-$(VERSION)/include/linux
Add Linux Compat Infrastructure Lay the initial ground work for a include/linux/ compatibility directory. This was less critical in the past because the bulk of the ZFS code consumes the Solaris API via the SPL. This API was stable and the bulk Linux API differences were handled in the SPL. However, with the addition of a full Posix layer written directly against the Linux APIs we are going to need more compatibility code. It makes sense that all this code should be cleanly located in one place. Subsequent patches should move the existing zvol and vdev_disk compatibility code in to this directory.
2011-01-18 22:42:25 +03:00
kernel_HEADERS = $(COMMON_H) $(KERNEL_H)
endif
Reference in New Issue Copy Permalink