d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
6998d5b1c8
freebsd-skq/sys/conf/files.amd64

478 lines
20 KiB
Plaintext
Raw Normal View History

This is the start of the FreeBSD/x86_64 kernel.
2002-06-30 08:05:21 +00:00
# This file tells config what files go into building a kernel,
# files marked standard are always included.
#
# $FreeBSD$
#
Create files.x86 files.x86 is for the parts of the system that are common to both i386 and amd64 due too their nature. First up, to get the ball rolling, is fdc, the floppy disk support. It works only on amd64 and i386 these days, and that's unlikely to change. Reviewed by: jhb, cem (earlier versrions) Differential Revision: https://reviews.freebsd.org/D21210
2019-08-12 22:58:56 +00:00
# common files stuff between i386 and amd64
include "conf/files.x86"
This is the start of the FreeBSD/x86_64 kernel.
2002-06-30 08:05:21 +00:00
# The long compile-with and dependency lines are required because of
# limitations in config: backslash-newline doesn't work in strings, and
# dependency lines other than the first are silently ignored.
#
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
#
Make execution of 32-bit CloudABI executables work on amd64. A nice thing about requiring a vDSO is that it makes it incredibly easy to provide full support for running 32-bit processes on 64-bit systems. Instead of letting the kernel be responsible for composing/decomposing 64-bit arguments across multiple registers/stack slots, all of this can now be done in the vDSO. This means that there is no need to provide duplicate copies of certain system calls, like the sys_lseek() and freebsd32_lseek() we have for COMPAT_FREEBSD32. This change imports a new vDSO from the CloudABI repository that has automatically generated code in it that copies system call arguments into a buffer, padding them to eight bytes and zero-extending any pointers/size_t arguments. After returning from the kernel, it does the inverse: extracting return values, in the process truncating pointers/size_t values to 32 bits. Obtained from: https://github.com/NuxiNL/cloudabi
2016-08-24 10:51:33 +00:00
cloudabi32_vdso.o optional compat_cloudabi32 \
dependency "$S/contrib/cloudabi/cloudabi_vdso_i686_on_64bit.S" \
compile-with "${CC} -x assembler-with-cpp -m32 -shared -nostdinc -nostdlib -Wl,-T$S/compat/cloudabi/cloudabi_vdso.lds $S/contrib/cloudabi/cloudabi_vdso_i686_on_64bit.S -o ${.TARGET}" \
no-obj no-implicit-rule \
clean "cloudabi32_vdso.o"
#
cloudabi32_vdso_blob.o optional compat_cloudabi32 \
dependency "cloudabi32_vdso.o" \
compile-with "${OBJCOPY} --input-target binary --output-target elf64-x86-64-freebsd --binary-architecture i386 cloudabi32_vdso.o ${.TARGET}" \
no-implicit-rule \
clean "cloudabi32_vdso_blob.o"
#
Provide the CloudABI vDSO to its executables. CloudABI executables already provide support for passing in vDSOs. This functionality is used by the emulator for OS X to inject system call handlers. On FreeBSD, we could use it to optimize calls to gettimeofday(), etc. Though I don't have any plans to optimize any system calls right now, let's go ahead and already pass in a vDSO. This will allow us to simplify the executables, as the traditional "syscall" shims can be removed entirely. It also means that we gain more flexibility with regards to adding and removing system calls. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D7438
2016-08-10 21:02:41 +00:00
cloudabi64_vdso.o optional compat_cloudabi64 \
Rewrite the vDSOs for CloudABI in assembly. The reason why the old vDSOs were written in C using inline assembly was purely because they were embedded in the C library directly as static inline functions. This was practical during development, because it meant you could invoke system calls without any library dependencies. The vDSO was simply a copy of these functions. Now that we require the use of the vDSO, there is no longer any need for embedding them in C code directly. Rewriting them in assembly has the advantage that they are closer to ideal (less useless branching, less assumptions about registers remaining unclobbered by the kernel, etc). They are also easier to build, as they no longer depend on the C type information for CloudABI. Obtained from: https://github.com/NuxiNL/cloudabi
2016-08-21 07:28:38 +00:00
dependency "$S/contrib/cloudabi/cloudabi_vdso_x86_64.S" \
Move the linker script from cloudabi64/ to cloudabi/. It turns out that it works perfectly fine for generating 32-bits vDSOs as well. While there, get rid of the extraneous .s file extension.
2016-08-21 15:14:06 +00:00
compile-with "${CC} -x assembler-with-cpp -shared -nostdinc -nostdlib -Wl,-T$S/compat/cloudabi/cloudabi_vdso.lds $S/contrib/cloudabi/cloudabi_vdso_x86_64.S -o ${.TARGET}" \
Provide the CloudABI vDSO to its executables. CloudABI executables already provide support for passing in vDSOs. This functionality is used by the emulator for OS X to inject system call handlers. On FreeBSD, we could use it to optimize calls to gettimeofday(), etc. Though I don't have any plans to optimize any system calls right now, let's go ahead and already pass in a vDSO. This will allow us to simplify the executables, as the traditional "syscall" shims can be removed entirely. It also means that we gain more flexibility with regards to adding and removing system calls. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D7438
2016-08-10 21:02:41 +00:00
no-obj no-implicit-rule \
clean "cloudabi64_vdso.o"
#
cloudabi64_vdso_blob.o optional compat_cloudabi64 \
dependency "cloudabi64_vdso.o" \
compile-with "${OBJCOPY} --input-target binary --output-target elf64-x86-64-freebsd --binary-architecture i386 cloudabi64_vdso.o ${.TARGET}" \
no-implicit-rule \
clean "cloudabi64_vdso_blob.o"
#
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
linux32_genassym.o optional compat_linux32 \
All genassym.sh usage need offset.inc
2018-07-03 21:02:25 +00:00
dependency "$S/amd64/linux32/linux32_genassym.c offset.inc" \
More fixes to build the kernel with a compiler that defaults to -fno-common Using the same approach as the last commit for the files used by genassym.sh. Obtained from: CheriBSD
2020-04-18 12:54:40 +00:00
compile-with "${CC} ${CFLAGS:N-flto:N-fno-common} -fcommon -c ${.IMPSRC}" \
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
no-obj no-implicit-rule \
clean "linux32_genassym.o"
#
linux32_assym.h optional compat_linux32 \
dependency "$S/kern/genassym.sh linux32_genassym.o" \
compile-with "sh $S/kern/genassym.sh linux32_genassym.o > ${.TARGET}" \
no-obj no-implicit-rule before-depend \
clean "linux32_assym.h"
#
Implement vdso - virtual dynamic shared object. Through vdso Linux exposes functions from kernel with proper DWARF CFI information so that it becomes easier to unwind through them. Using vdso is a mandatory for a thread cancelation && cleanup on a modern glibc. Differential Revision: https://reviews.freebsd.org/D1060
2015-05-24 15:28:17 +00:00
linux32_locore.o optional compat_linux32 \
linuxulator: rename linux_locore.s to .asm It is assembled using "${CC} -x assembler-with-cpp", which by convention (bsd.suffixes.mk) uses the .asm extension. This is a portion of the review referenced below (D18344). That review also renamed linux_support.s to .S, but that is a functional change (using the compiler's integrated assembler instead of as) and will be revisited separately. MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D18344
2019-07-30 17:18:31 +00:00
dependency "linux32_assym.h $S/amd64/linux32/linux32_locore.asm" \
Fix bogusly declared WERRORs in kernel build Many arm kernel configs bogusly specified WERROR=-Werror. There's no reason for this because the default is that and there's no reason to override. These date from a time when we needed to add additional warning->error suppression. They are obsolete and were cut and paste propagated from file to file. Comment out all the WERROR=.... lines in powerpc. They aren't bogus, but were appropriate for the old defaults for gcc4.2.1. Now that we've made the policy decision to suppress -Werror by default on these platforms, it is appropriate to comment these out. People wishing to fix these errors can still un-comment them out, or say WERROR=-Werror on the command line. Fix two instances (cut and paste propagation) of hard-coded -Werror in x86 code. Replace with ${WERROR} instead. This is a no-op change except for people who build WERROR=-Wno-error :). This should fix tinderbox / CI breakage.
2019-08-25 19:39:31 +00:00
compile-with "${CC} -x assembler-with-cpp -DLOCORE -m32 -shared -s -pipe -I. -I$S ${WERROR} -Wall -fPIC -fno-common -nostdinc -nostdlib -Wl,-T$S/amd64/linux32/linux32_vdso.lds.s -Wl,-soname=linux32_vdso.so,--eh-frame-hdr,-warn-common ${.IMPSRC} -o ${.TARGET}" \
Implement vdso - virtual dynamic shared object. Through vdso Linux exposes functions from kernel with proper DWARF CFI information so that it becomes easier to unwind through them. Using vdso is a mandatory for a thread cancelation && cleanup on a modern glibc. Differential Revision: https://reviews.freebsd.org/D1060
2015-05-24 15:28:17 +00:00
no-obj no-implicit-rule \
clean "linux32_locore.o"
#
linux32_vdso.so optional compat_linux32 \
dependency "linux32_locore.o" \
For objcopy, use --input-target and --output-target When building with gcc 4.9 and binutils 2.25, using '--input' and '--output' returns an error message: objcopy: option `--input' is ambiguous Reported by: Jenkins
2015-05-25 01:07:55 +00:00
compile-with "${OBJCOPY} --input-target binary --output-target elf64-x86-64-freebsd --binary-architecture i386 linux32_locore.o ${.TARGET}" \
Implement vdso - virtual dynamic shared object. Through vdso Linux exposes functions from kernel with proper DWARF CFI information so that it becomes easier to unwind through them. Using vdso is a mandatory for a thread cancelation && cleanup on a modern glibc. Differential Revision: https://reviews.freebsd.org/D1060
2015-05-24 15:28:17 +00:00
no-implicit-rule \
clean "linux32_vdso.so"
#
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
ia32_genassym.o standard \
ensure that offset.inc is generated before ia32_genassym.c is compiled
2018-07-03 05:56:23 +00:00
dependency "$S/compat/ia32/ia32_genassym.c offset.inc" \
More fixes to build the kernel with a compiler that defaults to -fno-common Using the same approach as the last commit for the files used by genassym.sh. Obtained from: CheriBSD
2020-04-18 12:54:40 +00:00
compile-with "${CC} ${CFLAGS:N-flto:N-fno-common} -fcommon -c ${.IMPSRC}" \
Add BASIC i386 binary support for the amd64 kernel. This is largely stolen from the ia64/ia32 code (indeed there was a repocopy), but I've redone the MD parts and added and fixed a few essential syscalls. It is sufficient to run i386 binaries like /bin/ls, /usr/bin/id (dynamic) and p4. The ia64 code has not implemented signal delivery, so I had to do that. Before you say it, yes, this does need to go in a common place. But we're in a freeze at the moment and I didn't want to risk breaking ia64. I will sort this out after the freeze so that the common code is in a common place. On the AMD64 side, this required adding segment selector context switch support and some other support infrastructure. The %fs/%gs etc code is hairy because loading %gs will clobber the kernel's current MSR_GSBASE setting. The segment selectors are not used by the kernel, so they're only changed at context switch time or when changing modes. This still needs to be optimized. Approved by: re (amd64/* blanket)
2003-05-14 04:10:49 +00:00
no-obj no-implicit-rule \
clean "ia32_genassym.o"
#
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
ia32_assym.h standard \
Add BASIC i386 binary support for the amd64 kernel. This is largely stolen from the ia64/ia32 code (indeed there was a repocopy), but I've redone the MD parts and added and fixed a few essential syscalls. It is sufficient to run i386 binaries like /bin/ls, /usr/bin/id (dynamic) and p4. The ia64 code has not implemented signal delivery, so I had to do that. Before you say it, yes, this does need to go in a common place. But we're in a freeze at the moment and I didn't want to risk breaking ia64. I will sort this out after the freeze so that the common code is in a common place. On the AMD64 side, this required adding segment selector context switch support and some other support infrastructure. The %fs/%gs etc code is hairy because loading %gs will clobber the kernel's current MSR_GSBASE setting. The segment selectors are not used by the kernel, so they're only changed at context switch time or when changing modes. This still needs to be optimized. Approved by: re (amd64/* blanket)
2003-05-14 04:10:49 +00:00
dependency "$S/kern/genassym.sh ia32_genassym.o" \
sys/conf: pass NMFLAGS to nm(1) via genassym.sh.
2015-08-14 22:58:32 +00:00
compile-with "env NM='${NM}' NMFLAGS='${NMFLAGS}' sh $S/kern/genassym.sh ia32_genassym.o > ${.TARGET}" \
Add BASIC i386 binary support for the amd64 kernel. This is largely stolen from the ia64/ia32 code (indeed there was a repocopy), but I've redone the MD parts and added and fixed a few essential syscalls. It is sufficient to run i386 binaries like /bin/ls, /usr/bin/id (dynamic) and p4. The ia64 code has not implemented signal delivery, so I had to do that. Before you say it, yes, this does need to go in a common place. But we're in a freeze at the moment and I didn't want to risk breaking ia64. I will sort this out after the freeze so that the common code is in a common place. On the AMD64 side, this required adding segment selector context switch support and some other support infrastructure. The %fs/%gs etc code is hairy because loading %gs will clobber the kernel's current MSR_GSBASE setting. The segment selectors are not used by the kernel, so they're only changed at context switch time or when changing modes. This still needs to be optimized. Approved by: re (amd64/* blanket)
2003-05-14 04:10:49 +00:00
no-obj no-implicit-rule before-depend \
clean "ia32_assym.h"
#
Port acpica to amd64. Approved by: re (amd64/* blanket)
2003-05-31 06:47:05 +00:00
amd64/acpica/acpi_machdep.c optional acpi
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 21:08:35 +00:00
acpi_wakecode.o optional acpi \
Rename assym.s to assym.inc assym is only to be included by other .s files, and should never actually be assembled by itself. Reviewed by: imp, bdrewery (earlier) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D14180
2018-03-20 17:58:51 +00:00
dependency "$S/amd64/acpica/acpi_wakecode.S assym.inc" \
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 21:08:35 +00:00
compile-with "${NORMAL_S}" \
Initial suspend/resume support for amd64. This code is heavily inspired by Takanori Watanabe's experimental SMP patch for i386 and large portion was shamelessly cut and pasted from Peter Wemm's AP boot code.
2009-03-17 00:48:11 +00:00
no-obj no-implicit-rule before-depend \
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 21:08:35 +00:00
clean "acpi_wakecode.o"
acpi_wakecode.bin optional acpi \
dependency "acpi_wakecode.o" \
Replace a bare use of 'objcopy' with ${OBJCOPY} for easier cross compilation in environments where 'objcopy' is spelled differently. Submitted by: John Van Horne <jvanhorne@juniper.net>
2012-09-12 13:58:18 +00:00
compile-with "${OBJCOPY} -S -O binary acpi_wakecode.o ${.TARGET}" \
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 21:08:35 +00:00
no-obj no-implicit-rule before-depend \
clean "acpi_wakecode.bin"
acpi_wakecode.h optional acpi \
dependency "acpi_wakecode.bin" \
compile-with "file2c -sx 'static char wakecode[] = {' '};' < acpi_wakecode.bin > ${.TARGET}" \
no-obj no-implicit-rule before-depend \
clean "acpi_wakecode.h"
acpi_wakedata.h optional acpi \
dependency "acpi_wakecode.o" \
Stop hard coding nm(1) and make it overridable.
2010-10-14 23:31:58 +00:00
compile-with '${NM} -n --defined-only acpi_wakecode.o | while read offset dummy what; do echo "#define $${what} 0x$${offset}"; done > ${.TARGET}' \
Move i386-inherited logic of building ACPI headers for acpi_wakeup.c into better places and remove intermediate makefile and shell scripts. This makes parallel kernel build little bit safer for amd64.
2010-07-12 21:08:35 +00:00
no-obj no-implicit-rule before-depend \
clean "acpi_wakedata.h"
Initial suspend/resume support for amd64. This code is heavily inspired by Takanori Watanabe's experimental SMP patch for i386 and large portion was shamelessly cut and pasted from Peter Wemm's AP boot code.
2009-03-17 00:48:11 +00:00
#
Fixed profiling of trap, syscall and interrupt handlers and some ordinary functions, essentially by backing out half of rev.1.115 of amd64/exception.S. The handlers must be between certain labels for the purposes of profiling, and this was broken by scattering them in separately compiled .S files, especially for ordinary functions that ended up between the labels. Merge the files by #including them as before, except with different pathnames and better comments and organization. Changes to the scattered files are minimal -- just move the labels to the file that does the #includes. This also partly fixes profiling of IPIs -- all IPI handlers are now correctly classified as interrupt handlers, but many are still missing mcount calls.
2004-05-24 12:08:56 +00:00
#amd64/amd64/apic_vector.S standard
Converge towards i386. I originally resisted creating <machine/pc/bios.h> because it was mostly irrelevant - except for the silly BIOS_PADDRTOVADDR etc macros. Along the way of working around this, I missed a few things. * Make syscons properly inherit the bios capslock/shiftlock/etc state like i386 does. Note that we cannot inherit the bios key repeat rate because that requires a bios call (which is impossible for us). * Give syscons the ability to beep on amd64. Oops. While here, make bios.c compile and add it to files.amd64.
2004-09-24 01:08:34 +00:00
amd64/amd64/bios.c standard
Add BPF Just-In-Time compiler support for ng_bpf(4). The sysctl is changed from net.bpf.jitter.enable to net.bpf_jitter.enable and this controls both bpf(4) and ng_bpf(4) now.
2005-12-07 21:30:47 +00:00
amd64/amd64/bpf_jit_machdep.c optional bpf_jitter
Use SMAP on amd64. Ifuncs selectors dispatch copyin(9) family to the suitable variant, to set rflags.AC around userspace access. Rflags.AC bit is cleared in all kernel entry points unconditionally even on machines not supporting SMAP. Reviewed by: jhb Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D13838
2018-07-29 20:47:00 +00:00
amd64/amd64/copyout.c standard
Spell cpu_switch correctly.
2003-05-03 03:30:29 +00:00
amd64/amd64/cpu_switch.S standard
Add ddb machdep bits. Approved by: re (amd64 bits)
2003-05-30 01:03:43 +00:00
amd64/amd64/db_disasm.c optional ddb
amd64/amd64/db_interface.c optional ddb
amd64/amd64/db_trace.c optional ddb
To prepare for adding EFI runtime services support on arm64 move the machine independent parts of the existing code to a new file that can be shared between amd64 and arm64. Reviewed by: kib (previous version), imp Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D12434
2017-10-01 19:52:47 +00:00
amd64/amd64/efirt_machdep.c optional efirt
Catch exceptions during EFI RT calls on amd64. This appeared to be required to have EFI RT support and EFI RTC enabled by default, because there are too many reports of faulting calls on many different machines. The knob is added to leave the exceptions unhandled to allow to debug the actual bugs. Reviewed by: kevans Sponsored by: The FreeBSD Foundation MFC after: 1 week Approved by: re (rgrimes) Differential revision: https://reviews.freebsd.org/D16972
2018-09-02 21:37:05 +00:00
amd64/amd64/efirt_support.S optional efirt
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/elf_machdep.c standard
Rename amd64/*.s to amd64/*.S
2003-05-03 00:19:42 +00:00
amd64/amd64/exception.S standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
amd64/amd64/fpu.c standard
Hook the GDB backend into the build.
2004-07-10 23:31:17 +00:00
amd64/amd64/gdb_machdep.c optional gdb
Compile in in_cksum* implementations for both IPv6 and IPv6. While in_pseudo() etc. is often used in offloading feature support, in_cksum() is mostly used to fix some broken hardware. Keeping both around for the moment allows us to compile NIC drivers even in an IPv6 only environment without the need to mangle them with #ifdef INETs in a way they are not prepared for. This will leave some dead code paths that will not be exercised for IPv6. Reviewed by: gnn Sponsored by: The FreeBSD Foundation Sponsored by: iXsystems MFC after: 3 days
2011-04-20 12:58:30 +00:00
amd64/amd64/in_cksum.c optional inet | inet6
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/initcpu.c standard
Break out the MI part of the /dev/[k]mem and /dev/io drivers into their own directory and module, leaving the MD parts in the MD area (the MD parts _are_ part of the modules). /dev/mem and /dev/io are now loadable modules, thus taking us one step further towards a kernel created entirely out of modules. Of course, there is nothing preventing the kernel from having these statically compiled.
2004-08-01 11:40:54 +00:00
amd64/amd64/io.c optional io
Rename amd64/*.s to amd64/*.S
2003-05-03 00:19:42 +00:00
amd64/amd64/locore.S standard no-obj
xen-locore: Silence DWARF2 section warning Silence the "DWARF2 can only represent one section per compilation unit" warning in amd64 GENERIC builds by disabling Clang's debuginfo generation for this assembler file (-g0). The message is replaced by a warning from ctfconvert that there is no debuginfo to convert (future work). The file contains some metadata (several ELF notes) and some code. The code does not appear to have anything that debuginfo would aid. I looked at the generated debuginfo (readelf -w xen-locore.o) prior to this change, and the metadata that would be disabled are things like associated between binary offset and code line number (not especially useful with a disassembler), and label metadata for the entry points (not especially useful as this is already in the symbol table). Reviewed by: royger Differential Revision: https://reviews.freebsd.org/D24384
2020-04-17 20:20:03 +00:00
amd64/amd64/xen-locore.S optional xenhvm \
Don't try ctfconvert on file without debug info. This was currently an ignored error but will change to a hard error eventually. Differential Revision: https://reviews.freebsd.org/D24536
2020-04-28 16:09:25 +00:00
compile-with "${NORMAL_S} -g0" \
no-ctfconvert
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/machdep.c standard
Break out the MI part of the /dev/[k]mem and /dev/io drivers into their own directory and module, leaving the MD parts in the MD area (the MD parts _are_ part of the modules). /dev/mem and /dev/io are now loadable modules, thus taking us one step further towards a kernel created entirely out of modules. Of course, there is nothing preventing the kernel from having these statically compiled.
2004-08-01 11:40:54 +00:00
amd64/amd64/mem.c optional mem
Introduce minidumps. Full physical memory crash dumps are still available via the debug.minidump sysctl and tunable. Traditional dumps store all physical memory. This was once a good thing when machines had a maximum of 64M of ram and 1GB of kvm. These days, machines often have many gigabytes of ram and a smaller amount of kvm. libkvm+kgdb don't have a way to access physical ram that is not mapped into kvm at the time of the crash dump, so the extra ram being dumped is mostly wasted. Minidumps invert the process. Instead of dumping physical memory in in order to guarantee that all of kvm's backing is dumped, minidumps instead dump only memory that is actively mapped into kvm. amd64 has a direct map region that things like UMA use. Obviously we cannot dump all of the direct map region because that is effectively an old style all-physical-memory dump. Instead, introduce a bitmap and two helper routines (dump_add_page(pa) and dump_drop_page(pa)) that allow certain critical direct map pages to be included in the dump. uma_machdep.c's allocator is the intended consumer. Dumps are a custom format. At the very beginning of the file is a header, then a copy of the message buffer, then the bitmap of pages present in the dump, then the final level of the kvm page table trees (2MB mappings are expanded into a 4K page mappings), then the sparse physical pages according to the bitmap. libkvm can now conveniently access the kvm page table entries. Booting my test 8GB machine, forcing it into ddb and forcing a dump leads to a 48MB minidump. While this is a best case, I expect minidumps to be in the 100MB-500MB range. Obviously, never larger than physical memory of course. minidumps are on by default. It would want be necessary to turn them off if it was necessary to debug corrupt kernel page table management as that would mess up minidumps as well. Both minidumps and regular dumps are supported on the same machine.
2006-04-21 04:24:50 +00:00
amd64/amd64/minidump_machdep.c standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
amd64/amd64/mp_machdep.c optional smp
amd64/amd64/mpboot.S optional smp
Eliminate compilation warnings due to the use of non-static inlines through the introduction and use of the __gnu89_inline attribute. Submitted by: bde (i386) MFC after: 3 days
2007-12-09 21:00:36 +00:00
amd64/amd64/pmap.c standard
Fixed insertion sort error in previous commit (prof_machdep.c). Fixed apparently-intentional disorder of the crypto files. Lists of files should be sorted first on the pathname, not on the option name or subsystem.
2004-05-24 09:55:02 +00:00
amd64/amd64/prof_machdep.c optional profiling-routine
Add support for the extended FPU states on amd64, both for native 64bit and 32bit ABIs. As a side-effect, it enables AVX on capable CPUs. In particular: - Query the CPU support for XSAVE, list of the supported extensions and the required size of FPU save area. The hw.use_xsave tunable is provided for disabling XSAVE, and hw.xsave_mask may be used to select the enabled extensions. - Remove the FPU save area from PCB and dynamically allocate the (run-time sized) user save area on the top of the kernel stack, right above the PCB. Reorganize the thread0 PCB initialization to postpone it after BSP is queried for save area size. - The dumppcb, stoppcbs and susppcbs now do not carry the FPU state as well. FPU state is only useful for suspend, where it is saved in dynamically allocated suspfpusave area. - Use XSAVE and XRSTOR to save/restore FPU state, if supported and enabled. - Define new mcontext_t flag _MC_HASFPXSTATE, indicating that mcontext_t has a valid pointer to out-of-struct extended FPU state. Signal handlers are supplied with stack-allocated fpu state. The sigreturn(2) and setcontext(2) syscall honour the flag, allowing the signal handlers to inspect and manipilate extended state in the interrupted context. - The getcontext(2) never returns extended state, since there is no place in the fixed-sized mcontext_t to place variable-sized save area. And, since mcontext_t is embedded into ucontext_t, makes it impossible to fix in a reasonable way. Instead of extending getcontext(2) syscall, provide a sysarch(2) facility to query extended FPU state. - Add ptrace(2) support for getting and setting extended state; while there, implement missed PT_I386_{GET,SET}XMMREGS for 32bit binaries. - Change fpu_kern KPI to not expose struct fpu_kern_ctx layout to consumers, making it opaque. Internally, struct fpu_kern_ctx now contains a space for the extended state. Convert in-kernel consumers of fpu_kern KPI both on i386 and amd64. First version of the support for AVX was submitted by Tim Bird <tim.bird am sony com> on behalf of Sony. This version was written from scratch. Tested by: pho (previous version), Yamagi Burmeister <lists yamagi org> MFC after: 1 month
2012-01-21 17:45:27 +00:00
amd64/amd64/ptrace_machdep.c standard
Rename amd64/*.s to amd64/*.S
2003-05-03 00:19:42 +00:00
amd64/amd64/sigtramp.S standard
amd64/amd64/support.S standard
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/sys_machdep.c standard
amd64/amd64/trap.c standard
Introduce uiomove_fromphys(). This is a variant of uiomove() that takes a collection of physical pages as the source. On amd64 it is implemented using the direct virtual-to-physical map.
2004-03-20 19:36:29 +00:00
amd64/amd64/uio_machdep.c standard
MFia64 Move uma_small_alloc() and uma_small_free() to uma_machdep.c.
2003-10-14 05:51:31 +00:00
amd64/amd64/uma_machdep.c standard
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
amd64/amd64/vm_machdep.c standard
Make execution of 32-bit CloudABI executables work on amd64. A nice thing about requiring a vDSO is that it makes it incredibly easy to provide full support for running 32-bit processes on 64-bit systems. Instead of letting the kernel be responsible for composing/decomposing 64-bit arguments across multiple registers/stack slots, all of this can now be done in the vDSO. This means that there is no need to provide duplicate copies of certain system calls, like the sys_lseek() and freebsd32_lseek() we have for COMPAT_FREEBSD32. This change imports a new vDSO from the CloudABI repository that has automatically generated code in it that copies system call arguments into a buffer, padding them to eight bytes and zero-extending any pointers/size_t arguments. After returning from the kernel, it does the inverse: extracting return values, in the process truncating pointers/size_t values to 32 bits. Obtained from: https://github.com/NuxiNL/cloudabi
2016-08-24 10:51:33 +00:00
amd64/cloudabi32/cloudabi32_sysvec.c optional compat_cloudabi32
Add a sysentvec for CloudABI on x86-64. Summary: For CloudABI we need to put two things on the stack of new processes: the argument data (a binary blob; not strings) and a startup data structure. The startup data structure contains interesting things such as a pointer to the ELF program header, the thread ID of the initial thread, a stack smashing protection canary, and a pointer to the argument data. Fetching system call arguments and setting the return value is similar to FreeBSD. The only differences are that system call 0 does not exist and that we call into cloudabi_convert_errno() to convert the error code. We also need this function in a couple of other places, so we'd better reuse it here. Reviewers: dchagin, kib Reviewed By: kib Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3098
2015-07-16 18:24:06 +00:00
amd64/cloudabi64/cloudabi64_sysvec.c optional compat_cloudabi64
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
amd64/pci/pci_cfgreg.c optional pci
Allow DTrace to be compiled-in to the kernel. This will require for AArch64 as we dont have modules yet. Sponsored by: HEIF5 Sponsored by: ARM Ltd. Differential Revision: https://reviews.freebsd.org/D1997
2015-06-10 15:53:39 +00:00
cddl/dev/dtrace/amd64/dtrace_asm.S optional dtrace compile-with "${DTRACE_S}"
cddl/dev/dtrace/amd64/dtrace_subr.c optional dtrace compile-with "${DTRACE_C}"
Crypto(4) driver for AESNI. The aeskeys_{amd64,i386}.S content was mostly obtained from OpenBSD, no objections to the license from core. Hardware provided by: Sentex Communications Tested by: fabient, pho (previous versions) MFC after: 1 month
2010-07-23 11:00:46 +00:00
crypto/aesni/aeskeys_amd64.S optional aesni
Remove support for DES and Triple DES from OCF. It no longer has any in-kernel consumers via OCF. smbfs still uses single DES directly, so sys/crypto/des remains for that use case. Reviewed by: cem Relnotes: yes Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D24773
2020-05-11 21:34:29 +00:00
crypto/des/des_enc.c optional netsmb
Add a kernel crypto driver using assembly routines from OpenSSL. Currently, this supports SHA1 and SHA2-{224,256,384,512} both as plain hashes and in HMAC mode on both amd64 and i386. It uses the SHA intrinsics when present similar to aesni(4), but uses SSE/AVX instructions when they are not. Note that some files from OpenSSL that normally wrap the assembly routines have been adapted to export methods usable by 'struct auth_xform' as is used by existing software crypto routines. Reviewed by: gallatin, jkim, delphij, gnn Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D26821
2020-10-20 17:50:18 +00:00
crypto/openssl/amd64/sha1-x86_64.S optional ossl
crypto/openssl/amd64/sha256-x86_64.S optional ossl
crypto/openssl/amd64/sha512-x86_64.S optional ossl
* Driver for ACPI WMI (Windows Management Instrumentation) * Driver for ACPI HP extra functionations, which required ACPI WMI driver. Submitted by: Michael <freebsdusb at bindone.de> Approved by: re MFC after: 2 weeks
2009-06-23 13:17:25 +00:00
dev/acpi_support/acpi_wmi_if.m standard
- Add few VIA bridges to agp_via.c and connect it to amd64 build as they support Intel Core/Core 2 and VIA Nano processors. - Align "optional agp" in conf/files.* for consistency while I am here.
2009-01-23 17:48:18 +00:00
dev/agp/agp_amd64.c optional agp
dev/agp/agp_i810.c optional agp
dev/agp/agp_via.c optional agp
Add amdgpio, driver for GPIO controller on AMD-based x86_64 platforms Submitted by: Rajesh Kumar <rajbsd@gmail.com> Differential Revision: https://reviews.freebsd.org/D16865
2018-10-21 04:52:37 +00:00
dev/amdgpio/amdgpio.c optional amdgpio
10Gigabit Ethernet driver for AMD SoC This patch has the driver for 10Gigabit Ethernet controller in AMD SoC. This driver is written compatible to the Iflib framework. The existing driver is for the old version of hardware. The submitted driver here is for the recent versions of the hardware where the Ethernet controller is PCI-E based. Submitted by: Rajesh Kumar <rajesh1.kumar@amd.com> MFC after: 1 month Relnotes: yes Differential Revision: https://reviews.freebsd.org/D25793
2020-10-11 16:01:16 +00:00
dev/axgbe/if_axgbe_pci.c optional axp
dev/axgbe/xgbe-desc.c optional axp
dev/axgbe/xgbe-dev.c optional axp
dev/axgbe/xgbe-drv.c optional axp
dev/axgbe/xgbe-mdio.c optional axp
dev/axgbe/xgbe-sysctl.c optional axp
dev/axgbe/xgbe-txrx.c optional axp
dev/axgbe/xgbe_osdep.c optional axp
dev/axgbe/xgbe-i2c.c optional axp
dev/axgbe/xgbe-phy-v2.c optional axp
Move all the sys/dev/[a-j]* that are common to files.x86 All these device entries are common between the two files. Move them to files.x86. Also sort entries from this range into proper order in files.amd64.
2019-10-30 19:53:46 +00:00
dev/hyperv/vmbus/amd64/hyperv_machdep.c optional hyperv
dev/hyperv/vmbus/amd64/vmbus_vector.S optional hyperv
ice(4): Introduce new driver for Intel E800 Ethernet controllers The ice(4) driver is the driver for the Intel E8xx series Ethernet controllers; currently with codenames Columbiaville and Columbia Park. These new controllers support 100G speeds, as well as introducing more queues, better virtualization support, and more offload capabilities. Future work will enable virtual functions (like in ixl(4)) and the other functionality outlined above. For full functionality, the kernel should be compiled with "device ice_ddp" like in the amd64 NOTES file, and/or ice_ddp_load="YES" should be added to /boot/loader.conf so that the DDP package file included in this commit can be downloaded to the adapter. Otherwise, the adapter will fall back to a single queue mode with limited functionality. A man page for this driver will be forthcoming. MFC after: 1 month Relnotes: yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D21959
2020-05-26 23:35:10 +00:00
dev/ice/if_ice_iflib.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_lib.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_osdep.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_resmgr.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_strings.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_iflib_recovery_txrx.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_iflib_txrx.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_common.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_controlq.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_dcb.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_flex_pipe.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_flow.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_nvm.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_sched.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_sriov.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
dev/ice/ice_switch.c optional ice pci \
compile-with "${NORMAL_C} -I$S/dev/ice"
ice_ddp.c optional ice_ddp \
ice_ddp: Update package file to 1.3.16.0 This package is intended to be used with ice(4) version 0.26.16. That update will happen in a forthcoming commit. MFC after: 3 days Sponsored by: Intel Corporation
2020-09-04 17:37:58 +00:00
compile-with "${AWK} -f $S/tools/fw_stub.awk ice_ddp.fw:ice_ddp:0x01031000 -mice_ddp -c${.TARGET}" \
ice(4): Introduce new driver for Intel E800 Ethernet controllers The ice(4) driver is the driver for the Intel E8xx series Ethernet controllers; currently with codenames Columbiaville and Columbia Park. These new controllers support 100G speeds, as well as introducing more queues, better virtualization support, and more offload capabilities. Future work will enable virtual functions (like in ixl(4)) and the other functionality outlined above. For full functionality, the kernel should be compiled with "device ice_ddp" like in the amd64 NOTES file, and/or ice_ddp_load="YES" should be added to /boot/loader.conf so that the DDP package file included in this commit can be downloaded to the adapter. Otherwise, the adapter will fall back to a single queue mode with limited functionality. A man page for this driver will be forthcoming. MFC after: 1 month Relnotes: yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D21959
2020-05-26 23:35:10 +00:00
no-implicit-rule before-depend local \
clean "ice_ddp.c"
ice_ddp.fwo optional ice_ddp \
dependency "ice_ddp.fw" \
compile-with "${NORMAL_FWO}" \
no-implicit-rule \
clean "ice_ddp.fwo"
ice_ddp.fw optional ice_ddp \
ice_ddp: Update package file to 1.3.16.0 This package is intended to be used with ice(4) version 0.26.16. That update will happen in a forthcoming commit. MFC after: 3 days Sponsored by: Intel Corporation
2020-09-04 17:37:58 +00:00
dependency "$S/contrib/dev/ice/ice-1.3.16.0.pkg" \
compile-with "${CP} $S/contrib/dev/ice/ice-1.3.16.0.pkg ice_ddp.fw" \
ice(4): Introduce new driver for Intel E800 Ethernet controllers The ice(4) driver is the driver for the Intel E8xx series Ethernet controllers; currently with codenames Columbiaville and Columbia Park. These new controllers support 100G speeds, as well as introducing more queues, better virtualization support, and more offload capabilities. Future work will enable virtual functions (like in ixl(4)) and the other functionality outlined above. For full functionality, the kernel should be compiled with "device ice_ddp" like in the amd64 NOTES file, and/or ice_ddp_load="YES" should be added to /boot/loader.conf so that the DDP package file included in this commit can be downloaded to the adapter. Otherwise, the adapter will fall back to a single queue mode with limited functionality. A man page for this driver will be forthcoming. MFC after: 1 month Relnotes: yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D21959
2020-05-26 23:35:10 +00:00
no-obj no-implicit-rule \
clean "ice_ddp.fw"
Import ioat(4) driver I/OAT is also referred to as Crystal Beach DMA and is a Platform Storage Extension (PSE) on some Intel server platforms. This driver currently supports DMA descriptors only and is part of a larger effort to upstream an interconnect between multiple systems using the Non-Transparent Bridge (NTB) PSE. For now, this driver is only built on AMD64 platforms. It may be ported to work on i386 later, if that is desired. The hardware is exclusive to x86. Further documentation on ioat(4), including API documentation and usage, can be found in the new manual page. Bring in a test tool, ioatcontrol(8), in tools/tools/ioat. The test tool is not hooked up to the build and is not intended for end users. Submitted by: jimharris, Carl Delsey <carl.r.delsey@intel.com> Reviewed by: jimharris (reviewed my changes) Approved by: markj (mentor) Relnotes: yes Sponsored by: Intel Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D3456
2015-08-24 19:32:03 +00:00
dev/ioat/ioat.c optional ioat pci
dev/ioat/ioat_test.c optional ioat pci
As per [1] Intel only supports this driver on 64bit platforms. For now restrict it to amd64. Other architectures might be re-added later once tested. Remove the drivers from the global NOTES and files files and move them to the amd64 specifics. Remove the drivers from the i386 modules build and only leave the amd64 version. Rather than depending on "inet" depend on "pci" and make sure that ixl(4) and ixlv(4) can be compiled independently [2]. This also allows the drivers to build properly on IPv4-only or IPv6-only kernels. PR: 193824 [2] Reviewed by: eric.joyner intel.com MFC after: 3 days References: [1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
2014-09-23 08:33:03 +00:00
dev/ixl/if_ixl.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl(4): Update to ixl-1.6.6-k. Submitted by: erj Reviewed by: jeffrey.e.pieper@intel.com MFC after: 3 days Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D7391
2016-08-07 18:12:36 +00:00
dev/ixl/ixl_pf_main.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl(4): Add FW recovery mode support and other things Update the iflib version of ixl driver based on the OOT version ixl-1.11.29. Major changes: - Extract iflib specific functions from ixl_pf_main.c to ixl_pf_iflib.c to simplify code sharing between legacy and iflib version of driver - Add support for most recent FW API version (1.10), which extends FW LLDP Agent control by user to X722 devices - Improve handling of device global reset - Add support for the FW recovery mode - Use virtchnl function to validate virtual channel messages instead of using separate checks - Fix MAC/VLAN filters accounting Submitted by: Krzysztof Galazka <krzysztof.galazka@intel.com> Reviewed by: erj@ Tested by: Jeffrey Pieper <jeffrey.e.pieper@intel.com> MFC after: 1 week Relnotes: yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D24564
2020-06-09 22:42:54 +00:00
dev/ixl/ixl_pf_iflib.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl(4): Update to ixl-1.6.6-k. Submitted by: erj Reviewed by: jeffrey.e.pieper@intel.com MFC after: 3 days Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D7391
2016-08-07 18:12:36 +00:00
dev/ixl/ixl_pf_qmgr.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
Fix kldload of if_ixl without PCI_IOV kernel option. This also avoids compiling in pci_iov support into the kernel if_ixoif the PCI_IOV option is disabled. Reviewed by: rstone Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D11573
2017-07-13 22:45:23 +00:00
dev/ixl/ixl_pf_iov.c optional ixl pci pci_iov \
ixl(4): Update to ixl-1.6.6-k. Submitted by: erj Reviewed by: jeffrey.e.pieper@intel.com MFC after: 3 days Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D7391
2016-08-07 18:12:36 +00:00
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl(4): Update to 1.7.12-k Refresh upstream driver before impending conversion to iflib. Major new features: - Support for Fortville-based 25G adapters - Support for I2C reads/writes (To prevent getting or sending corrupt data, you should set dev.ixl.0.debug.disable_fw_link_management=1 when using I2C [this will disable link!], then set it to 0 when done. The driver implements the SIOCGI2C ioctl, so ifconfig -v works for reading I2C data, but there are read_i2c and write_i2c sysctls under the .debug sysctl tree [the latter being useful for upper page support in QSFP+]). - Addition of an iWARP client interface (so the future iWARP driver for X722 devices can communicate with the base driver). - Compiling this option in is enabled by default, with "options IXL_IW" in GENERIC. Differential Revision: https://reviews.freebsd.org/D9227 Reviewed by: sbruno MFC after: 2 weeks Sponsored by: Intel Corporation
2017-02-10 01:04:11 +00:00
dev/ixl/ixl_pf_i2c.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
iavf(4): Finish rename/rebrand internally Rename functions and variables from ixlv to iavf to match the user-facing name change. There shouldn't be any functional changes with this change, but this may help with browsing the source code and reducing diffs in the future. Submitted by: kbowling@ Reviewed by: erj@, sbruno@ Approved by: re (gjb@) Differential Revision: https://reviews.freebsd.org/D17544
2018-10-15 17:23:41 +00:00
dev/ixl/if_iavf.c optional iavf pci \
As per [1] Intel only supports this driver on 64bit platforms. For now restrict it to amd64. Other architectures might be re-added later once tested. Remove the drivers from the global NOTES and files files and move them to the amd64 specifics. Remove the drivers from the i386 modules build and only leave the amd64 version. Rather than depending on "inet" depend on "pci" and make sure that ixl(4) and ixlv(4) can be compiled independently [2]. This also allows the drivers to build properly on IPv4-only or IPv6-only kernels. PR: 193824 [2] Reviewed by: eric.joyner intel.com MFC after: 3 days References: [1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
2014-09-23 08:33:03 +00:00
compile-with "${NORMAL_C} -I$S/dev/ixl"
iavf(4): Finish rename/rebrand internally Rename functions and variables from ixlv to iavf to match the user-facing name change. There shouldn't be any functional changes with this change, but this may help with browsing the source code and reducing diffs in the future. Submitted by: kbowling@ Reviewed by: erj@, sbruno@ Approved by: re (gjb@) Differential Revision: https://reviews.freebsd.org/D17544
2018-10-15 17:23:41 +00:00
dev/ixl/iavf_vc.c optional iavf pci \
As per [1] Intel only supports this driver on 64bit platforms. For now restrict it to amd64. Other architectures might be re-added later once tested. Remove the drivers from the global NOTES and files files and move them to the amd64 specifics. Remove the drivers from the i386 modules build and only leave the amd64 version. Rather than depending on "inet" depend on "pci" and make sure that ixl(4) and ixlv(4) can be compiled independently [2]. This also allows the drivers to build properly on IPv4-only or IPv6-only kernels. PR: 193824 [2] Reviewed by: eric.joyner intel.com MFC after: 3 days References: [1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
2014-09-23 08:33:03 +00:00
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl/iavf(4): Change ixlv to iavf and update it to use iflib(9) Finishes the conversion of the 40Gb Intel Ethernet drivers to iflib(9) for FreeBSD 12.0, and fixes numerous bugs in both ixl(4) and iavf(4). This commit also re-adds the VF driver to GENERIC since it now compiles and functions. The VF driver name was changed from ixlv(4) to iavf(4) because the VF driver is now intended to be used with future products, not just with Fortville/Fort Park VFs. A man page update that documents these drivers is forthcoming in a separate commit. Reviewed by: sbruno@, kbowling@ Tested by: jeffrey.e.pieper@intel.com Approved by: re (gjb@) Relnotes: yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D16429
2018-10-12 22:40:54 +00:00
dev/ixl/ixl_txrx.c optional ixl pci | iavf pci \
As per [1] Intel only supports this driver on 64bit platforms. For now restrict it to amd64. Other architectures might be re-added later once tested. Remove the drivers from the global NOTES and files files and move them to the amd64 specifics. Remove the drivers from the i386 modules build and only leave the amd64 version. Rather than depending on "inet" depend on "pci" and make sure that ixl(4) and ixlv(4) can be compiled independently [2]. This also allows the drivers to build properly on IPv4-only or IPv6-only kernels. PR: 193824 [2] Reviewed by: eric.joyner intel.com MFC after: 3 days References: [1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
2014-09-23 08:33:03 +00:00
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl/iavf(4): Change ixlv to iavf and update it to use iflib(9) Finishes the conversion of the 40Gb Intel Ethernet drivers to iflib(9) for FreeBSD 12.0, and fixes numerous bugs in both ixl(4) and iavf(4). This commit also re-adds the VF driver to GENERIC since it now compiles and functions. The VF driver name was changed from ixlv(4) to iavf(4) because the VF driver is now intended to be used with future products, not just with Fortville/Fort Park VFs. A man page update that documents these drivers is forthcoming in a separate commit. Reviewed by: sbruno@, kbowling@ Tested by: jeffrey.e.pieper@intel.com Approved by: re (gjb@) Relnotes: yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D16429
2018-10-12 22:40:54 +00:00
dev/ixl/i40e_osdep.c optional ixl pci | iavf pci \
As per [1] Intel only supports this driver on 64bit platforms. For now restrict it to amd64. Other architectures might be re-added later once tested. Remove the drivers from the global NOTES and files files and move them to the amd64 specifics. Remove the drivers from the i386 modules build and only leave the amd64 version. Rather than depending on "inet" depend on "pci" and make sure that ixl(4) and ixlv(4) can be compiled independently [2]. This also allows the drivers to build properly on IPv4-only or IPv6-only kernels. PR: 193824 [2] Reviewed by: eric.joyner intel.com MFC after: 3 days References: [1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
2014-09-23 08:33:03 +00:00
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl/iavf(4): Change ixlv to iavf and update it to use iflib(9) Finishes the conversion of the 40Gb Intel Ethernet drivers to iflib(9) for FreeBSD 12.0, and fixes numerous bugs in both ixl(4) and iavf(4). This commit also re-adds the VF driver to GENERIC since it now compiles and functions. The VF driver name was changed from ixlv(4) to iavf(4) because the VF driver is now intended to be used with future products, not just with Fortville/Fort Park VFs. A man page update that documents these drivers is forthcoming in a separate commit. Reviewed by: sbruno@, kbowling@ Tested by: jeffrey.e.pieper@intel.com Approved by: re (gjb@) Relnotes: yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D16429
2018-10-12 22:40:54 +00:00
dev/ixl/i40e_lan_hmc.c optional ixl pci | iavf pci \
As per [1] Intel only supports this driver on 64bit platforms. For now restrict it to amd64. Other architectures might be re-added later once tested. Remove the drivers from the global NOTES and files files and move them to the amd64 specifics. Remove the drivers from the i386 modules build and only leave the amd64 version. Rather than depending on "inet" depend on "pci" and make sure that ixl(4) and ixlv(4) can be compiled independently [2]. This also allows the drivers to build properly on IPv4-only or IPv6-only kernels. PR: 193824 [2] Reviewed by: eric.joyner intel.com MFC after: 3 days References: [1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
2014-09-23 08:33:03 +00:00
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl/iavf(4): Change ixlv to iavf and update it to use iflib(9) Finishes the conversion of the 40Gb Intel Ethernet drivers to iflib(9) for FreeBSD 12.0, and fixes numerous bugs in both ixl(4) and iavf(4). This commit also re-adds the VF driver to GENERIC since it now compiles and functions. The VF driver name was changed from ixlv(4) to iavf(4) because the VF driver is now intended to be used with future products, not just with Fortville/Fort Park VFs. A man page update that documents these drivers is forthcoming in a separate commit. Reviewed by: sbruno@, kbowling@ Tested by: jeffrey.e.pieper@intel.com Approved by: re (gjb@) Relnotes: yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D16429
2018-10-12 22:40:54 +00:00
dev/ixl/i40e_hmc.c optional ixl pci | iavf pci \
As per [1] Intel only supports this driver on 64bit platforms. For now restrict it to amd64. Other architectures might be re-added later once tested. Remove the drivers from the global NOTES and files files and move them to the amd64 specifics. Remove the drivers from the i386 modules build and only leave the amd64 version. Rather than depending on "inet" depend on "pci" and make sure that ixl(4) and ixlv(4) can be compiled independently [2]. This also allows the drivers to build properly on IPv4-only or IPv6-only kernels. PR: 193824 [2] Reviewed by: eric.joyner intel.com MFC after: 3 days References: [1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
2014-09-23 08:33:03 +00:00
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl/iavf(4): Change ixlv to iavf and update it to use iflib(9) Finishes the conversion of the 40Gb Intel Ethernet drivers to iflib(9) for FreeBSD 12.0, and fixes numerous bugs in both ixl(4) and iavf(4). This commit also re-adds the VF driver to GENERIC since it now compiles and functions. The VF driver name was changed from ixlv(4) to iavf(4) because the VF driver is now intended to be used with future products, not just with Fortville/Fort Park VFs. A man page update that documents these drivers is forthcoming in a separate commit. Reviewed by: sbruno@, kbowling@ Tested by: jeffrey.e.pieper@intel.com Approved by: re (gjb@) Relnotes: yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D16429
2018-10-12 22:40:54 +00:00
dev/ixl/i40e_common.c optional ixl pci | iavf pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/i40e_nvm.c optional ixl pci | iavf pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
dev/ixl/i40e_adminq.c optional ixl pci | iavf pci \
As per [1] Intel only supports this driver on 64bit platforms. For now restrict it to amd64. Other architectures might be re-added later once tested. Remove the drivers from the global NOTES and files files and move them to the amd64 specifics. Remove the drivers from the i386 modules build and only leave the amd64 version. Rather than depending on "inet" depend on "pci" and make sure that ixl(4) and ixlv(4) can be compiled independently [2]. This also allows the drivers to build properly on IPv4-only or IPv6-only kernels. PR: 193824 [2] Reviewed by: eric.joyner intel.com MFC after: 3 days References: [1] http://lists.freebsd.org/pipermail/svn-src-all/2014-August/090470.html
2014-09-23 08:33:03 +00:00
compile-with "${NORMAL_C} -I$S/dev/ixl"
ixl(4): Update to 1.9.9-k Refresh upstream driver before impending conversion to iflib. Major changes: - Support for descriptor writeback mode (required by ixlv(4) for AVF support) - Ability to disable firmware LLDP agent by user (PR 221530) - Fix for TX queue hang when using TSO (PR 221919) - Separate descriptor ring sizes for TX and RX rings PR: 221530, 221919 Submitted by: Krzysztof Galazka <krzysztof.galazka@intel.com> Reviewed by: #IntelNetworking MFC after: 1 day Relnotes: Yes Sponsored by: Intel Corporation Differential Revision: https://reviews.freebsd.org/D14985
2018-05-01 18:50:12 +00:00
dev/ixl/i40e_dcb.c optional ixl pci \
compile-with "${NORMAL_C} -I$S/dev/ixl"
Add nctgpio conf lines so it can be compiled into the kernel. MFC after: 2 days
2017-03-30 15:05:10 +00:00
dev/nctgpio/nctgpio.c optional nctgpio
Add a pure open source nForce Ethernet driver, under BSDL. This driver was ported from OpenBSD by Shigeaki Tagashira <shigeaki@se.hiroshima-u.ac.jp> and posted at http://www.se.hiroshima-u.ac.jp/~shigeaki/software/freebsd-nfe.html It was additionally cleaned up by me. It is still a work-in-progress and thus is purposefully not in GENERIC. And it conflicts with nve(4), so only one should be loaded.
2006-06-26 23:41:07 +00:00
dev/nfe/if_nfe.c optional nfe pci
Add a new driver to support the Intel Non-Transparent Bridge(NTB). The NTB allows you to connect two systems with this device using a PCI-e link. The driver is made of two modules: - ntb_hw which is a basic hardware abstraction layer for the device. - if_ntb which implements the ntb network device and the communication protocol. The driver is limited at the moment to CPU memcpy instead of using DMA, and only Back-to-Back mode is supported. Also the network device isn't full featured yet. These changes will be coming soon. The DMA change will also bring in the ioat driver from the project branch it is on now. This is an initial port of the GPL/BSD Linux driver contributed by Jon Mason from Intel. Any bugs are my contributions. Sponsored by: Intel Reviewed by: jimharris, joel (man page only) Approved by: jimharris (mentor)
2013-04-29 22:48:53 +00:00
dev/ntb/if_ntb/if_ntb.c optional if_ntb
Add NTB driver for PLX/Avago/Broadcom PCIe switches. This driver supports both NTB-to-NTB and NTB-to-Root Port modes (though the second with predictable complications on hot-plug and reboot events). I tested it with PEX 8717 and PEX 8733 chips, but expect it should work with many other compatible ones too. It supports up to two NT bridges per chip, each of which can have up to 2 64-bit or 4 32-bit memory windows, 6 or 12 scratchpad registers and 16 doorbells. There are also 4 DMA engines in those chips, but they are not yet supported. While there, rename Intel NTB driver from generic ntb_hw(4) to more specific ntb_hw_intel(4), so now it is on par with this new ntb_hw_plx(4) driver and alike to Linux naming. MFC after: 2 weeks Sponsored by: iXsystems, Inc.
2017-08-30 21:16:32 +00:00
dev/ntb/ntb_transport.c optional ntb_transport | if_ntb
Add driver for NTB in AMD SoC. This patch is the driver for NTB hardware in AMD SoCs (ported from Linux) and enables the NTB infrastructure like Doorbells, Scratchpads and Memory window in AMD SoC. This driver has been validated using ntb_transport and if_ntb driver already available in FreeBSD. Submitted by: Rajesh Kumar <rajesh1.kumar@amd.com> MFC after: 1 month Relnotes: yes Differential Revision: https://reviews.freebsd.org/D18774
2019-07-02 05:25:18 +00:00
dev/ntb/ntb.c optional ntb | ntb_transport | if_ntb | ntb_hw_amd | ntb_hw_intel | ntb_hw_plx | ntb_hw
dev/ntb/ntb_if.m optional ntb | ntb_transport | if_ntb | ntb_hw_amd | ntb_hw_intel | ntb_hw_plx | ntb_hw
dev/ntb/ntb_hw/ntb_hw_amd.c optional ntb_hw_amd | ntb_hw
Add NTB driver for PLX/Avago/Broadcom PCIe switches. This driver supports both NTB-to-NTB and NTB-to-Root Port modes (though the second with predictable complications on hot-plug and reboot events). I tested it with PEX 8717 and PEX 8733 chips, but expect it should work with many other compatible ones too. It supports up to two NT bridges per chip, each of which can have up to 2 64-bit or 4 32-bit memory windows, 6 or 12 scratchpad registers and 16 doorbells. There are also 4 DMA engines in those chips, but they are not yet supported. While there, rename Intel NTB driver from generic ntb_hw(4) to more specific ntb_hw_intel(4), so now it is on par with this new ntb_hw_plx(4) driver and alike to Linux naming. MFC after: 2 weeks Sponsored by: iXsystems, Inc.
2017-08-30 21:16:32 +00:00
dev/ntb/ntb_hw/ntb_hw_intel.c optional ntb_hw_intel | ntb_hw
dev/ntb/ntb_hw/ntb_hw_plx.c optional ntb_hw_plx | ntb_hw
NTB Tool: Test driver for NTB hardware drivers. NTB Tool driver is meant for testing NTB hardware driver functionalities, such as doorbell interrupts, link events, scratchpad registers and memory windows. This is a port of ntb_tool driver from Linux. It has been verified on top of AMD and PLX NTB HW drivers. Submitted by: Arpan Palit <arpan.palit@amd.com> Cleaned up by: mav MFC after: 2 weeks Relnotes: yes Differential Revision: https://reviews.freebsd.org/D18819
2019-08-16 20:14:37 +00:00
dev/ntb/test/ntb_tool.c optional ntb_tool
Split /dev/nvram driver out of isa/clock.c for i386 and amd64. I have not refactored it to be a generic device. Instead of being part of the standard kernel, there is now a 'nvram' device for i386/amd64. It is in DEFAULTS like io and mem, and can be turned off with 'nodevice nvram'. This matches the previous behavior when it was first committed.
2007-10-26 03:23:54 +00:00
dev/nvram/nvram.c optional nvram isa
random(4): Fix RANDOM_LOADABLE build I introduced an obvious compiler error in r346282, so this change fixes that. Unfortunately, RANDOM_LOADABLE isn't covered by our existing tinderbox, and it seems like there were existing latent linking problems. I believe these were introduced on accident in r338324 during reduction of the boolean expression(s) adjacent to randomdev.c and hash.c. It seems the RANDOM_LOADABLE build breakage has gone unnoticed for nine months. This change correctly annotates randomdev.c and hash.c with !random_loadable to match the pre-r338324 logic; and additionally updates the HWRNG drivers in MD 'files.*', which depend on random_device symbols, with !random_loadable (it is invalid for the kernel to depend on symbols from a module). (The expression for both randomdev.c and hash.c was the same, prior to r338324: "optional random random_yarrow | random !random_yarrow !random_loadable". I.e., "random && (yarrow || !loadable)." When Yarrow was removed ("yarrow := False"), the expression was incorrectly reduced to "optional random" when it should have retained "random && !loadable".) Additionally, I discovered that virtio_random was missing a MODULE_DEPEND on random_device, which breaks kld load/link of the driver on RANDOM_LOADABLE kernels. Address that issue as well. PR: 238223 Reported by: Eir Nym <eirnym AT gmail.com> Reviewed by: delphij, markm Approved by: secteam(delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D20466
2019-06-01 01:22:21 +00:00
dev/random/ivy.c optional rdrand_rng !random_loadable
dev/random/nehemiah.c optional padlock_rng !random_loadable
Add Qlogic 10Gb Ethernet Driver for Qlogic 8100 Series CNA Adapter Driver version (v2.0.0) Submitted by: David C Somayajulu (davidcs@freebsd.org) QLogic Corporation Approved by: George Neville-Neil (gnn@freebsd.org)
2013-06-25 17:50:22 +00:00
dev/qlxge/qls_dbg.c optional qlxge pci
dev/qlxge/qls_dump.c optional qlxge pci
dev/qlxge/qls_hw.c optional qlxge pci
dev/qlxge/qls_ioctl.c optional qlxge pci
dev/qlxge/qls_isr.c optional qlxge pci
dev/qlxge/qls_os.c optional qlxge pci
Add QLogic 10 Gigabit Ethernet & CNA Adapter Driver version 1.30 for 3200 and 8200 series cards. Submitted by: David C Somayajulu (david.somayajulu@qlogic.com), Qlogic Corporation MFC After: 3 days
2011-11-03 21:20:22 +00:00
dev/qlxgb/qla_dbg.c optional qlxgb pci
dev/qlxgb/qla_hw.c optional qlxgb pci
dev/qlxgb/qla_ioctl.c optional qlxgb pci
dev/qlxgb/qla_isr.c optional qlxgb pci
dev/qlxgb/qla_misc.c optional qlxgb pci
dev/qlxgb/qla_os.c optional qlxgb pci
Add Qlogic 10Gigabit Ethernet & CNA Adapter Driver Version 3.10.10 for QLogic 8300 Series Adapters Submitted by: David C Somayajulu (davidcs@freebsd.org) QLogic Corporation Approved by: George Neville-Neil (gnn@freebsd.org)
2013-05-15 17:03:09 +00:00
dev/qlxgbe/ql_dbg.c optional qlxgbe pci
dev/qlxgbe/ql_hw.c optional qlxgbe pci
dev/qlxgbe/ql_ioctl.c optional qlxgbe pci
dev/qlxgbe/ql_isr.c optional qlxgbe pci
dev/qlxgbe/ql_misc.c optional qlxgbe pci
dev/qlxgbe/ql_os.c optional qlxgbe pci
dev/qlxgbe/ql_reset.c optional qlxgbe pci
Fix qlxgbe(4) static build. MFC after: 2 weeks
2019-06-26 16:23:24 +00:00
dev/qlxgbe/ql_fw.c optional qlxgbe pci
dev/qlxgbe/ql_boot.c optional qlxgbe pci
dev/qlxgbe/ql_minidump.c optional qlxgbe pci
Cleanup the bitmap_xxx() functions in the LinuxKPI: - Move all bitmap related functions from bitops.h to bitmap.h, similar to what Linux does. - Apply some minor code cleanup and simplifications to optimize the generated code when using static inline functions. - Implement the following list of bitmap functions which are needed by drm-next and ibcore: - bitmap_find_next_zero_area_off() - bitmap_find_next_zero_area() - bitmap_or() - bitmap_and() - bitmap_xor() - Add missing include directives to the qlnxe driver (davidcs@ has been notified) MFC after: 1 week Sponsored by: Mellanox Technologies
2017-04-06 13:30:31 +00:00
dev/qlnx/qlnxe/ecore_cxt.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_dbg_fw_funcs.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_dcbx.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_dev.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_hw.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_init_fw_funcs.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_init_ops.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_int.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_l2.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_mcp.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_sp_commands.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_spq.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/qlnx_ioctl.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/qlnx_os.c optional qlnxe pci \
compile-with "${LINUXKPI_C}"
Update file list for sfgxe(4) again and hey, my amd64 kernels compile again.
2016-05-14 08:55:15 +00:00
dev/sfxge/common/ef10_ev.c optional sfxge pci
dev/sfxge/common/ef10_filter.c optional sfxge pci
sfxge(4): add firmware image layout option Submitted by: Andy Moreton <amoreton at solarflare.com> Sponsored by: Solarflare Communications, Inc. Differential Revision: https://reviews.freebsd.org/D18214
2018-11-29 06:29:24 +00:00
dev/sfxge/common/ef10_image.c optional sfxge pci
Update file list for sfgxe(4) again and hey, my amd64 kernels compile again.
2016-05-14 08:55:15 +00:00
dev/sfxge/common/ef10_intr.c optional sfxge pci
dev/sfxge/common/ef10_mac.c optional sfxge pci
dev/sfxge/common/ef10_mcdi.c optional sfxge pci
dev/sfxge/common/ef10_nic.c optional sfxge pci
dev/sfxge/common/ef10_nvram.c optional sfxge pci
dev/sfxge/common/ef10_phy.c optional sfxge pci
dev/sfxge/common/ef10_rx.c optional sfxge pci
dev/sfxge/common/ef10_tx.c optional sfxge pci
dev/sfxge/common/ef10_vpd.c optional sfxge pci
sfxge: add 7xxx NICs family support Support 7xxx adapters including firmware-assisted TSO and VLAN tagging: - Solarflare Flareon Ultra 7000 series 10/40G adapters: - Solarflare SFN7042Q QSFP+ Server Adapter - Solarflare SFN7142Q QSFP+ Server Adapter - Solarflare Flareon Ultra 7000 series 10G adapters: - Solarflare SFN7022F SFP+ Server Adapter - Solarflare SFN7122F SFP+ Server Adapter - Solarflare SFN7322F Precision Time Synchronization Server Adapter - Solarflare Flareon 7000 series 10G adapters: - Solarflare SFN7002F SFP+ Server Adapter Support utilities to configure adapters and update firmware. The work is done by Solarflare developers (Andy Moreton, Andrew Lee and many others), Artem V. Andreev <Artem.Andreev at oktetlabs.ru> and me. Sponsored by: Solarflare Communications, Inc. MFC after: 2 weeks Causually read by: gnn Differential Revision: https://reviews.freebsd.org/D2618
2015-05-25 08:34:55 +00:00
dev/sfxge/common/efx_bootcfg.c optional sfxge pci
dev/sfxge/common/efx_crc32.c optional sfxge pci
dev/sfxge/common/efx_ev.c optional sfxge pci
dev/sfxge/common/efx_filter.c optional sfxge pci
dev/sfxge/common/efx_hash.c optional sfxge pci
dev/sfxge/common/efx_intr.c optional sfxge pci
sfxge: add accessors for license-related MCDI calls to common code Add support for Huntington MCDI licensing interface to common code. Ported from Linux net driver IOCTL functions with restructuring for initial support for V3 licensing API. Submitted by: Richard Houldsworth <rhouldsworth at solarflare.com> Reviewed by: gnn Sponsored by: Solarflare Communications, Inc. MFC after: 2 days Differential Revision: https://reviews.freebsd.org/D4918
2016-01-14 09:19:28 +00:00
dev/sfxge/common/efx_lic.c optional sfxge pci
sfxge: add 7xxx NICs family support Support 7xxx adapters including firmware-assisted TSO and VLAN tagging: - Solarflare Flareon Ultra 7000 series 10/40G adapters: - Solarflare SFN7042Q QSFP+ Server Adapter - Solarflare SFN7142Q QSFP+ Server Adapter - Solarflare Flareon Ultra 7000 series 10G adapters: - Solarflare SFN7022F SFP+ Server Adapter - Solarflare SFN7122F SFP+ Server Adapter - Solarflare SFN7322F Precision Time Synchronization Server Adapter - Solarflare Flareon 7000 series 10G adapters: - Solarflare SFN7002F SFP+ Server Adapter Support utilities to configure adapters and update firmware. The work is done by Solarflare developers (Andy Moreton, Andrew Lee and many others), Artem V. Andreev <Artem.Andreev at oktetlabs.ru> and me. Sponsored by: Solarflare Communications, Inc. MFC after: 2 weeks Causually read by: gnn Differential Revision: https://reviews.freebsd.org/D2618
2015-05-25 08:34:55 +00:00
dev/sfxge/common/efx_mac.c optional sfxge pci
dev/sfxge/common/efx_mcdi.c optional sfxge pci
dev/sfxge/common/efx_mon.c optional sfxge pci
dev/sfxge/common/efx_nic.c optional sfxge pci
dev/sfxge/common/efx_nvram.c optional sfxge pci
dev/sfxge/common/efx_phy.c optional sfxge pci
dev/sfxge/common/efx_port.c optional sfxge pci
dev/sfxge/common/efx_rx.c optional sfxge pci
dev/sfxge/common/efx_sram.c optional sfxge pci
sfxge(4): add API to control UDP tunnel ports HW needs to know which UDP packets should be treated as tunnel encapsulation to do inner packet recognition, classification and offloads. Submitted by: Ivan Malov <ivan.malov at oktetlabs.ru> Sponsored by: Solarflare Communications, Inc. Differential Revision: https://reviews.freebsd.org/D18134
2018-11-26 06:20:13 +00:00
dev/sfxge/common/efx_tunnel.c optional sfxge pci
sfxge: add 7xxx NICs family support Support 7xxx adapters including firmware-assisted TSO and VLAN tagging: - Solarflare Flareon Ultra 7000 series 10/40G adapters: - Solarflare SFN7042Q QSFP+ Server Adapter - Solarflare SFN7142Q QSFP+ Server Adapter - Solarflare Flareon Ultra 7000 series 10G adapters: - Solarflare SFN7022F SFP+ Server Adapter - Solarflare SFN7122F SFP+ Server Adapter - Solarflare SFN7322F Precision Time Synchronization Server Adapter - Solarflare Flareon 7000 series 10G adapters: - Solarflare SFN7002F SFP+ Server Adapter Support utilities to configure adapters and update firmware. The work is done by Solarflare developers (Andy Moreton, Andrew Lee and many others), Artem V. Andreev <Artem.Andreev at oktetlabs.ru> and me. Sponsored by: Solarflare Communications, Inc. MFC after: 2 weeks Causually read by: gnn Differential Revision: https://reviews.freebsd.org/D2618
2015-05-25 08:34:55 +00:00
dev/sfxge/common/efx_tx.c optional sfxge pci
dev/sfxge/common/efx_vpd.c optional sfxge pci
dev/sfxge/common/hunt_nic.c optional sfxge pci
Update file list for sfgxe(4) again and hey, my amd64 kernels compile again.
2016-05-14 08:55:15 +00:00
dev/sfxge/common/mcdi_mon.c optional sfxge pci
dev/sfxge/common/medford_nic.c optional sfxge pci
sfxge(4): add Medford2 support to NIC module Submitted by: Andy Moreton <amoreton at solarflare.com> Sponsored by: Solarflare Communications, Inc. Differential Revision: https://reviews.freebsd.org/D18142
2018-11-27 12:14:16 +00:00
dev/sfxge/common/medford2_nic.c optional sfxge pci
sfxge: add 7xxx NICs family support Support 7xxx adapters including firmware-assisted TSO and VLAN tagging: - Solarflare Flareon Ultra 7000 series 10/40G adapters: - Solarflare SFN7042Q QSFP+ Server Adapter - Solarflare SFN7142Q QSFP+ Server Adapter - Solarflare Flareon Ultra 7000 series 10G adapters: - Solarflare SFN7022F SFP+ Server Adapter - Solarflare SFN7122F SFP+ Server Adapter - Solarflare SFN7322F Precision Time Synchronization Server Adapter - Solarflare Flareon 7000 series 10G adapters: - Solarflare SFN7002F SFP+ Server Adapter Support utilities to configure adapters and update firmware. The work is done by Solarflare developers (Andy Moreton, Andrew Lee and many others), Artem V. Andreev <Artem.Andreev at oktetlabs.ru> and me. Sponsored by: Solarflare Communications, Inc. MFC after: 2 weeks Causually read by: gnn Differential Revision: https://reviews.freebsd.org/D2618
2015-05-25 08:34:55 +00:00
dev/sfxge/common/siena_mac.c optional sfxge pci
dev/sfxge/common/siena_mcdi.c optional sfxge pci
dev/sfxge/common/siena_nic.c optional sfxge pci
dev/sfxge/common/siena_nvram.c optional sfxge pci
dev/sfxge/common/siena_phy.c optional sfxge pci
dev/sfxge/common/siena_sram.c optional sfxge pci
dev/sfxge/common/siena_vpd.c optional sfxge pci
dev/sfxge/sfxge.c optional sfxge pci
dev/sfxge/sfxge_dma.c optional sfxge pci
dev/sfxge/sfxge_ev.c optional sfxge pci
dev/sfxge/sfxge_intr.c optional sfxge pci
dev/sfxge/sfxge_mcdi.c optional sfxge pci
dev/sfxge/sfxge_nvram.c optional sfxge pci
dev/sfxge/sfxge_port.c optional sfxge pci
dev/sfxge/sfxge_rx.c optional sfxge pci
dev/sfxge/sfxge_tx.c optional sfxge pci
martpqi(4): - Microsemi SCSI driver for PQI controllers. - Found on newer model HP servers. - Restrict to AMD64 only as per developer request. The driver provides support for the new generation of PQI controllers from Microsemi. This driver is the first SCSI driver to implement the PQI queuing model and it will replace the aacraid driver for Adaptec Series 9 controllers. HARDWARE Controllers supported by the driver include: HPE Gen10 Smart Array Controller Family OEM Controllers based on the Microsemi Chipset. Submitted by: deepak.ukey@microsemi.com Relnotes: yes Sponsored by: Microsemi Differential Revision: https://reviews.freebsd.org/D14514
2018-04-26 16:59:06 +00:00
dev/smartpqi/smartpqi_cam.c optional smartpqi
dev/smartpqi/smartpqi_cmd.c optional smartpqi
dev/smartpqi/smartpqi_discovery.c optional smartpqi
dev/smartpqi/smartpqi_event.c optional smartpqi
dev/smartpqi/smartpqi_helper.c optional smartpqi
dev/smartpqi/smartpqi_init.c optional smartpqi
dev/smartpqi/smartpqi_intr.c optional smartpqi
dev/smartpqi/smartpqi_ioctl.c optional smartpqi
dev/smartpqi/smartpqi_main.c optional smartpqi
dev/smartpqi/smartpqi_mem.c optional smartpqi
dev/smartpqi/smartpqi_misc.c optional smartpqi
dev/smartpqi/smartpqi_queue.c optional smartpqi
dev/smartpqi/smartpqi_request.c optional smartpqi
dev/smartpqi/smartpqi_response.c optional smartpqi
dev/smartpqi/smartpqi_sis.c optional smartpqi
dev/smartpqi/smartpqi_tag.c optional smartpqi
Add /dev/speaker support to amd64. The following repo-copies were made (by Mark Murray): sys/i386/isa/spkr.c -> sys/dev/speaker/spkr.c sys/i386/include/speaker.h -> sys/dev/speaker/speaker.h share/man/man4/man4.i386/spkr.4 -> share/man/man4/spkr.4
2005-11-11 09:57:32 +00:00
dev/speaker/spkr.c optional speaker
Driver for 4x10Gb Ethernet reference NIC FPGA design for NetFPGA SUME development board. Submitted by: Denis Salopek <denis.salopek AT fer.hr> Reported by: zec, bz (src); rgrimes, bcr (manpages) MFC after: 7 days Sponsored by: Google Summer of Code 2020 Differential Revision: https://reviews.freebsd.org/D26074
2020-08-30 07:34:32 +00:00
dev/sume/if_sume.c optional sume
add superio driver The goal of this driver is consolidate information about SuperIO chips and to provide for peaceful coexistence of drivers that need to access SuperIO configuration registers. While SuperIO chips can host various functions most of them are discoverable and accessible without any knowledge of the SuperIO. Examples are: keyboard and mouse controllers, UARTs, floppy disk controllers. SuperIO-s also provide non-standard functions such as GPIO, watchdog timers and hardware monitoring. Such functions do require drivers with a knowledge of a specific SuperIO. At this time the driver supports a number of ITE and Nuvoton (fka Winbond) SuperIO chips. There is a single driver for all devices. So, I have not done the usual split between the hardware driver and the bus functionality. Although, superio does act as a bus for devices that represent known non-standard functions of a SuperIO chip. The bus provides enumeration of child devices based on the hardcoded knowledge of such functions. The knowledge as extracted from datasheets and other drivers. As there is a single driver, I have not defined a kobj interface for it. So, its interface is currently made of simple functions. I think that we can the flexibility (and complications) when we actually need it. I am planning to convert nctgpio and wbwd to superio bus very soon. Also, I am working on itwd driver (watchdog in ITE SuperIO-s). Additionally, there is ithwm driver based on the reverted sensors import, but I am not sure how to integrate it given that we still lack any sensors interface. Discussed with: imp, jhb MFC after: 7 weeks Differential Revision: https://reviews.freebsd.org/D8175
2019-07-01 17:05:41 +00:00
dev/superio/superio.c optional superio isa
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
dev/syscons/apm/apm_saver.c optional apm_saver apm
Automatically depend on x86emu when vesa or dpms is being built into kernel. With this change the user no longer need to remember building this option. Submitted by: swell.k at gmail.com
2009-09-21 07:08:20 +00:00
dev/syscons/scvesactl.c optional sc vga vesa
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
dev/syscons/scvgarndr.c optional sc vga
Add support 'device tpm' for amd64. Add tpm(4)'s default setting to /boot/defaults/loader.conf. Add 'device tpm' to NOTES for amd64 and i386. Discussed with: takawata Approved by: imp (mentor)
2010-09-19 14:40:37 +00:00
dev/tpm/tpm.c optional tpm
Introduce driver for TPM 2.0 in CRB and FIFO (TIS) modes It was written basing on: TCG PC Client Platform TPM Profile (PTP) Specification Version 22, Revision 1.03. It only supports Locality 0. Interrupts are only supported in FIFO mode. The driver in FIFO mode was tested on x86 with Infineon SLB9665 discrete TPM chip. Driver in both modes was also tested on qemu with swtpm running on host. Submitted by: Kornel Duleba <mindal@semihalf.com> Obtained from: Semihalf Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D18048
2018-12-14 16:14:36 +00:00
dev/tpm/tpm20.c optional tpm
Revert r357349, since the clang 10.0.0 warning was actually correct, and the ! operator should have been a ~ instead: Merge r357348 from the clang 10.0.0 import branch: Disable new clang 10.0.0 warnings about converting the result of shift operations to a boolean in tpm(4): sys/dev/tpm/tpm_crb.c:301:32: error: converting the result of '<<' to a boolean; did you mean '(1 << (0)) != 0'? [-Werror,-Wint-in-bool-context] WR4(sc, TPM_CRB_CTRL_CANCEL, !TPM_CRB_CTRL_CANCEL_CMD); ^ sys/dev/tpm/tpm_crb.c:73:34: note: expanded from macro 'TPM_CRB_CTRL_CANCEL_CMD' #define TPM_CRB_CTRL_CANCEL_CMD BIT(0) ^ sys/dev/tpm/tpm20.h:60:19: note: expanded from macro 'BIT' #define BIT(x) (1 << (x)) ^ Such warnings can be useful in C++ contexts, but not so much in kernel drivers, where this type of bit twiddling is commonplace. So disable it for this case. Noticed by: cem MFC after: 3 days
2020-02-01 16:57:04 +00:00
dev/tpm/tpm_crb.c optional tpm acpi
Introduce driver for TPM 2.0 in CRB and FIFO (TIS) modes It was written basing on: TCG PC Client Platform TPM Profile (PTP) Specification Version 22, Revision 1.03. It only supports Locality 0. Interrupts are only supported in FIFO mode. The driver in FIFO mode was tested on x86 with Infineon SLB9665 discrete TPM chip. Driver in both modes was also tested on qemu with swtpm running on host. Submitted by: Kornel Duleba <mindal@semihalf.com> Obtained from: Semihalf Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D18048
2018-12-14 16:14:36 +00:00
dev/tpm/tpm_tis.c optional tpm acpi
Add support 'device tpm' for amd64. Add tpm(4)'s default setting to /boot/defaults/loader.conf. Add 'device tpm' to NOTES for amd64 and i386. Discussed with: takawata Approved by: imp (mentor)
2010-09-19 14:40:37 +00:00
dev/tpm/tpm_acpi.c optional tpm acpi
dev/tpm/tpm_isa.c optional tpm isa
uart_cpu_amd64.c and uart_cpu_i386.c (under sys/dev/uart) are identical now that the bus spaces are unified under sys/x86. Replace them with a single uart_cpu_x86.c. o delete uart_cpu_i386.c o move uart_cpu_amd64.c to uart_cpu_x86.c o update files.amd64 and files.i386 accordingly.
2012-04-11 02:42:01 +00:00
dev/uart/uart_cpu_x86.c optional uart
Add watchdog support for VIA south bridge chipset. Tested on VT8251, VX900 but CX700, VX800, VX855 should works. MFC after: 1 month Sponsored by: NETASQ
2011-12-12 09:50:33 +00:00
dev/viawd/viawd.c optional viawd
Move all the sys/dev/[a-j]* that are common to files.x86 All these device entries are common between the two files. Move them to files.x86. Also sort entries from this range into proper order in files.amd64.
2019-10-30 19:53:46 +00:00
dev/vmd/vmd.c optional vmd
dev/vmd/vmd_bus.c optional vmd_bus
Provide wbwd(4), a driver for the watchdog timer found on various Winbond Super I/O chips. With minor efforts it should be possible the extend the driver to support further chips/revisions available from Winbond. In the simplest case only new IDs need to be added, while different chipsets might require their own function to enter extended function mode, etc. Sponsored by: Sandvine Incorporated ULC (in 2011) Reviewed by: emaste, brueffer MFC after: 2 weeks
2012-03-06 18:44:52 +00:00
dev/wbwd/wbwd.c optional wbwd
xen: create a new PCI bus override When running as a Xen PVH Dom0 we need to add custom buses that override some of the functionality present in the ACPI PCI Bus and the PCI Bus. We currently override the ACPI PCI Bus, but not the PCI Bus, so add a new override for the PCI Bus and share the generic functions between them. Reported by: David P. Discher <dpd@dpdtech.com> Sponsored by: Citrix Systems R&D conf/files.amd64: - Add the new files. x86/xen/xen_pci_bus.c: - Generic file that contains the PCI overrides so they can be used by the several PCI specific buses. xen/xen_pci.h: - Prototypes for the generic overried functions. dev/xen/pci/xen_pci.c: - Xen specific override for the PCI bus. dev/xen/pci/xen_acpi_pci.c: - Xen specific override for the ACPI PCI bus.
2014-12-09 18:03:25 +00:00
dev/xen/pci/xen_acpi_pci.c optional xenhvm
dev/xen/pci/xen_pci.c optional xenhvm
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
isa/syscons_isa.c optional sc
isa/vga_isa.c optional vga
Rename timeevents.c to kern_clocksource.c. Suggested by: jhb@
2010-07-14 18:43:27 +00:00
kern/kern_clocksource.c standard
Finish COMPAT_AOUT support for amd64. It wasn't in any amd64 or MI file in /sys/conf, so was unavailable in configurations that don't use modules, and was not testable or notable in NOTES. Its normal configuration (not using a module) is still silently deprecated in aout(4) by not mentioning it there. Update i386 NOTES for COMPAT_AOUT. It is not i386-only, or even very MD. Sort its entry better. Finish gzip configuration (but not support) for amd64. gzip is really gzipped aout. It is currently broken even for i386 (a call to vm fails). amd64 has always attempted to configure and test it, but it depends on COMPAT_AOUT (as noted). The bug that it depends on unconfigured files was not detected since it is configured as a device. All other optional image activators are configured properly using an option.
2018-06-02 06:40:15 +00:00
kern/imgact_aout.c optional compat_aout
Enable first part of kld's on amd64. This is known to not work right yet, but building kld's is OK now and they can be loaded by kldload(2). (but the machine will likely crash soon afterwards, a "minor" problem :-) Brought to you by: my injured knee (from moving)
2004-05-16 20:11:38 +00:00
kern/link_elf_obj.c standard
Initial landing of SMP support for FreeBSD/amd64. - This is heavily derived from John Baldwin's apic/pci cleanup on i386. - I have completely rewritten or drastically cleaned up some other parts. (in particular, bootstrap) - This is still a WIP. It seems that there are some highly bogus bioses on nVidia nForce3-150 boards. I can't stress how broken these boards are. I have a workaround in mind, but right now the Asus SK8N is broken. The Gigabyte K8NPro (nVidia based) is also mind-numbingly hosed. - Most of my testing has been with SCHED_ULE. SCHED_4BSD works. - the apic and acpi components are 'standard'. - If you have an nVidia nForce3-150 board, you are stuck with 'device atpic' in addition, because they somehow managed to forget to connect the 8254 timer to the apic, even though its in the same silicon! ARGH! This directly violates the ACPI spec.
2003-11-17 08:58:16 +00:00
#
# IA32 binary support
#
Provide groundwork for 32-bit binary compatibility on non-x86 platforms, for upcoming 64-bit PowerPC and MIPS support. This renames the COMPAT_IA32 option to COMPAT_FREEBSD32, removes some IA32-specific code from MI parts of the kernel and enhances the freebsd32 compatibility code to support big-endian platforms. Reviewed by: kib, jhb
2010-03-11 14:49:06 +00:00
#amd64/ia32/ia32_exception.S optional compat_freebsd32
amd64/ia32/ia32_reg.c optional compat_freebsd32
amd64/ia32/ia32_signal.c optional compat_freebsd32
amd64/ia32/ia32_sigtramp.S optional compat_freebsd32
amd64/ia32/ia32_syscall.c optional compat_freebsd32
amd64/ia32/ia32_misc.c optional compat_freebsd32
compat/ia32/ia32_sysvec.c optional compat_freebsd32
- change the example of compiling only specific modules to not contain the linux module, since it is not cross-platform - move linprocfs from "files" and "options" to architecture specific files, since it only makes sense to build this for those architectures, where we also have a linuxolator - disable the build of the linuxolator on our tier-2 architecture "Alpha": * we don't have a linux_base port which supports Alpha and at the same time is not outdated/obsoleted upstream/in a good condition/ currently working * the upcomming new default linux base port is based upon Fedora Core 3 (security support via http://www.fedoralegacy.org), which isn't available for Alpha (like the current default linux base port which is based upon Red Hat 8) * nobody answered my request for testing it ~1 month ago on current@ and alpha@ (it doesn't surprises me, see above) * a SoC student wouldn't have to waste time on something which nobody is willing to test This does not remove the alpha specific MD files of the linuxolator yet. Discussed on: arch (mostly silence) Spiritual support by: scottl
2006-05-07 18:12:18 +00:00
compat/linprocfs/linprocfs.c optional linprocfs
Add in linsysfs. A linux 2.6 like sys filesystem to pacify the Linux LSI MegaRAID SAS utility. Sponsored by: IronPort Systems Man page help from: brueffer
2006-05-09 22:27:01 +00:00
compat/linsysfs/linsysfs.c optional linsysfs
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
#
# Linux/i386 binary support
#
amd64/linux32/linux32_dummy.c optional compat_linux32
amd64/linux32/linux32_machdep.c optional compat_linux32
Fix the dependency for the linux_support.s, explicitely add linux_assym.h. Reported by: rwatson In collaboration with: rdivacky Sponsored by: Google SoC 2007
2007-05-23 15:45:52 +00:00
amd64/linux32/linux32_support.s optional compat_linux32 \
dependency "linux32_assym.h"
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
amd64/linux32/linux32_sysent.c optional compat_linux32
amd64/linux32/linux32_sysvec.c optional compat_linux32
Move futex support code from <arch>/support.s into linux compat directory. Implement all futex atomic operations in assembler to not depend on the fuword() that does not allow to distinguish between -1 and failure return. Correctly return 0 from atomic operations on success. In collaboration with: rdivacky Tested by: Scot Hetzel <swhetzel gmail com>, Milos Vyletel <mvyletel mzm cz> Sponsored by: Google SoC 2007
2007-05-23 08:33:06 +00:00
compat/linux/linux_emul.c optional compat_linux32
Share a single bsd-linux errno table across MD consumers Three copies of the linuxulator linux_sysvec.c contained identical BSD to Linux errno translation tables, and future work to support other architectures will also use the same table. Move the table to a common file to be used by all. Make it 'const int' to place it in .rodata. (Some existing Linux architectures use MD errno values, but x86 and Arm share the generic set.) This change should introduce no functional change; a followup will add missing errno values. MFC after: 3 weeks Sponsored by: Turing Robotic Industries Inc. Differential Revision: https://reviews.freebsd.org/D14665
2018-03-16 14:46:38 +00:00
compat/linux/linux_errno.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
compat/linux/linux_file.c optional compat_linux32
Move linux_clone(), linux_fork(), linux_vfork() to a MI path.
2011-02-12 18:17:12 +00:00
compat/linux/linux_fork.c optional compat_linux32
Add the linux 2.6.x stuff (not used by default!): - TLS - complete - pid/tid mangling - complete - thread area - complete - futexes - complete with issues - clone() extension - complete with some possible minor issues - mq*/timer*/clock* stuff - complete but untested and the mq* stuff is disabled when not build as part of the kernel with native FreeBSD mq* support (module support for this will come later) Tested with: - linux-firefox - works, tested - linux-opera - works, tested - linux-realplay - doesnt work, issue with futexes - linux-skype - doesnt work, issue with futexes - linux-rt2-demo - works, tested - linux-acroread - doesnt work, unknown reason (coredump) and sometimes issue with futexes - various unix utilities in linux-base-gentoo3 and linux-base-fc4: everything tried worked On amd64 not everything is supported like on i386, the catchup is planned for later when the remaining bugs in the new functions are fixed. To test this new stuff, you have to run sysctl compat.linux.osrelease=2.6.16 to switch back use sysctl compat.linux.osrelease=2.4.2 Don't switch while running a linux program, strange things may or may not happen. Sponsored by: Google SoC 2006 Submitted by: rdivacky Some suggestions/help by: jhb, kib, manu@NetBSD.org, netchild
2006-08-15 12:54:30 +00:00
compat/linux/linux_futex.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
compat/linux/linux_getcwd.c optional compat_linux32
compat/linux/linux_ioctl.c optional compat_linux32
compat/linux/linux_ipc.c optional compat_linux32
compat/linux/linux_mib.c optional compat_linux32
compat/linux/linux_misc.c optional compat_linux32
Add linux_mmap.c to the appropriate conf/files. Reported by: kib@ MFC after: 1 week
2016-07-10 08:38:10 +00:00
compat/linux/linux_mmap.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
compat/linux/linux_signal.c optional compat_linux32
compat/linux/linux_socket.c optional compat_linux32
compat/linux/linux_stats.c optional compat_linux32
compat/linux/linux_sysctl.c optional compat_linux32
Add the linux 2.6.x stuff (not used by default!): - TLS - complete - pid/tid mangling - complete - thread area - complete - futexes - complete with issues - clone() extension - complete with some possible minor issues - mq*/timer*/clock* stuff - complete but untested and the mq* stuff is disabled when not build as part of the kernel with native FreeBSD mq* support (module support for this will come later) Tested with: - linux-firefox - works, tested - linux-opera - works, tested - linux-realplay - doesnt work, issue with futexes - linux-skype - doesnt work, issue with futexes - linux-rt2-demo - works, tested - linux-acroread - doesnt work, unknown reason (coredump) and sometimes issue with futexes - various unix utilities in linux-base-gentoo3 and linux-base-fc4: everything tried worked On amd64 not everything is supported like on i386, the catchup is planned for later when the remaining bugs in the new functions are fixed. To test this new stuff, you have to run sysctl compat.linux.osrelease=2.6.16 to switch back use sysctl compat.linux.osrelease=2.4.2 Don't switch while running a linux program, strange things may or may not happen. Sponsored by: Google SoC 2006 Submitted by: rdivacky Some suggestions/help by: jhb, kib, manu@NetBSD.org, netchild
2006-08-15 12:54:30 +00:00
compat/linux/linux_time.c optional compat_linux32
Implement most of timer_{create,settime,gettime,getoverrun,delete} for amd64/linux32. Fix the entirely bogus (untested) version from r161310 for i386/linux using the same shared code in compat/linux. It is unclear to me if we could support more clock mappings but the current set allows me to successfully run commercial 32bit linux software under linuxolator on amd64. Reviewed by: jhb Differential Revision: D784 MFC after: 3 days Sponsored by: DARPA, AFRL
2014-09-18 08:36:45 +00:00
compat/linux/linux_timer.c optional compat_linux32
Add preliminary support for running 32-bit Linux binaries on amd64, enabled with the COMPAT_LINUX32 option. This is largely based on the i386 MD Linux emulations bits, but also builds on the 32-bit FreeBSD and generic IA-32 binary emulation work. Some of this is still a little rough around the edges, and will need to be revisited before 32-bit and 64-bit Linux emulation support can coexist in the same kernel.
2004-08-16 07:55:06 +00:00
compat/linux/linux_uid16.c optional compat_linux32
compat/linux/linux_util.c optional compat_linux32
Implement vdso - virtual dynamic shared object. Through vdso Linux exposes functions from kernel with proper DWARF CFI information so that it becomes easier to unwind through them. Using vdso is a mandatory for a thread cancelation && cleanup on a modern glibc. Differential Revision: https://reviews.freebsd.org/D1060
2015-05-24 15:28:17 +00:00
compat/linux/linux_vdso.c optional compat_linux32
Introduce a new module linux_common.ko which is intended for the following primary purposes: 1. Remove the dependency of linsysfs and linprocfs modules from linux.ko, which will be architecture specific on amd64. 2. Incorporate into linux_common.ko general code for platforms on which we'll support two Linuxulator modules (for both instruction set - 32 & 64 bit). 3. Move malloc(9) declaration to linux_common.ko, to enable getting memory usage statistics properly. Currently linux_common.ko incorporates a code from linux_mib.c and linux_util.c and linprocfs, linsysfs and linux kernel modules depend on linux_common.ko. Temporarily remove dtrace garbage from linux_mib.c and linux_util.c Differential Revision: https://reviews.freebsd.org/D1072 In collaboration with: Vassilis Laganakos. Reviewed by: trasz
2015-05-24 15:51:18 +00:00
compat/linux/linux_common.c optional compat_linux32
Implement epoll family system calls. This is a tiny wrapper around kqueue() to implement epoll subset of functionality. The kqueue user data are 32bit on i386 which is not enough for epoll user data, so we keep user data in the proc emuldata. Initial patch developed by rdivacky@ in 2007, then extended by Yuri Victorovich @ r255672 and finished by me in collaboration with mjg@ and jillies@. Differential Revision: https://reviews.freebsd.org/D1092
2015-05-24 16:41:39 +00:00
compat/linux/linux_event.c optional compat_linux32
Rework signal code to allow using it by other modules, like linprocfs: 1. Linux sigset always 64 bit on all platforms. In order to move Linux sigset code to the linux_common module define it as 64 bit int. Move Linux sigset manipulation routines to the MI path. 2. Move Linux signal number definitions to the MI path. In general, they are the same on all platforms except for a few signals. 3. Map Linux RT signals to the FreeBSD RT signals and hide signal conversion tables to avoid conversion errors. 4. Emulate Linux SIGPWR signal via FreeBSD SIGRTMIN signal which is outside of allowed on Linux signal numbers. PR: 197216
2015-05-24 17:47:20 +00:00
compat/linux/linux.c optional compat_linux32
Add in the Linux IOCTL shim and create the megadev0 device so Linux LSI MegaRaid tools can run on FreeBSD until Linux emulation. Add in the Linux IOCTL shim and create the megadev0 device so Linux LSI MegaRaid tools can run on FreeBSD until Linux emulation. Add glue to build the modules but don't tie it into the build yet until I test it from the CVS repo. via the mirror on an amd64 machine. Tie this into the Linux32 emulation on amd64 so the tools can run on amd64 kernel. Cleaned up by: ps (amr_linux.c)
2006-01-24 21:13:50 +00:00
dev/amr/amr_linux.c optional compat_linux32 amr
Add in a bunch of things to the mfi driver: - Linux ioctl support, with the other Linux changes MegaCli will run if you mount linprocfs & linsysfs then set sysctl compat.linux.osrelease=2.6.12 or similar. This works on i386. It should work on amd64 but not well tested yet. StoreLib may or may not work. Remember to kldload mfi_linux. - Add in AEN (Async Event Notification) support so we can get messages from the firmware when something happens. Not all messages are in defined in event detail. Use event_log to try to figure out what happened. - Try to implement something like SIGIO for StoreLib. Since mrmonitor doesn't work right I can't fully test it. StoreLib works best with the rh9 base. In theory mrmonitor isn't needed due to native driver support of AEN :-) Now we can configure and monitor the RAID better. Submitted by: IronPort Systems.
2006-05-18 23:30:48 +00:00
dev/mfi/mfi_linux.c optional compat_linux32 mfi
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
compat/ndis/winx64_wrap.S optional ndisapi pci
Be more conservative and compile libkern/memset.c only on architectures than need it. These are i386, amd64 and powerpc so far.
2007-04-06 04:51:50 +00:00
#
Remove leftover from r282269. MFC after: 2 weeks X-MFC with: r282269
2015-04-30 17:49:35 +00:00
# x86 real mode BIOS emulator, required by dpms/pci/vesa
Hide x86bios stuff in i386/amd64 specific files as atkbdc would get these stuff into build.
2009-09-22 07:10:23 +00:00
#
Remove leftover from r282269. MFC after: 2 weeks X-MFC with: r282269
2015-04-30 17:49:35 +00:00
compat/x86bios/x86bios.c optional x86bios | dpms | pci | vesa
contrib/x86emu/x86emu.c optional x86bios | dpms | pci | vesa
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 14:13:39 +00:00
#
bhyve import part 2 of 2, guest kernel changes. This branch is now considered frozen: future bhyve development will take place in a branch off -CURRENT. sys/dev/bvm/bvm_console.c sys/dev/bvm/bvm_dbg.c - simple console driver/gdb debug port used for bringup. supported by user-space bhyve executable sys/conf/options.amd64 sys/amd64/amd64/minidump_machdep.c - allow NKPT to be set in the kernel config file sys/amd64/conf/GENERIC - mptable config options; bhyve user-space executable creates an mptable with number of CPUs, and optional vendor extension - add bvm console/debug - set NKPT to 512 to allow loading of large RAM disks from the loader - include kdb/gdb sys/amd64/amd64/local_apic.c sys/amd64/amd64/apic_vector.S sys/amd64/include/specialreg.h - if x2apic mode available, use MSRs to access the local APIC, otherwise fall back to 'classic' MMIO mode sys/amd64/amd64/mp_machdep.c - support AP spinup on CPU models that don't have real-mode support by overwriting the real-mode page with a message that supplies the bhyve user-space executable with enough information to start the AP directly in 64-bit mode. sys/amd64/amd64/vm_machdep.c - insert pause statements into cpu shutdown busy-wait loops sys/dev/blackhole/blackhole.c sys/modules/blackhole/Makefile - boot-time loadable module that claims all PCI bus/slot/funcs specified in an env var that are to be used for PCI passthrough sys/amd64/amd64/intr_machdep.c - allow round-robin assignment of device interrupts to CPUs to be disabled from the loader sys/amd64/include/bus.h - convert string ins/outs instructions to loops of individual in/out since bhyve doesn't support these yet sys/kern/subr_bus.c - if the device was no created with a fixed devclass, then remove it's association with the devclass it was associated with during probe. Otherwise, new drivers do not get a chance to probe/attach since the device will stay married to the first driver that it probed successfully but failed to attach. Sponsored by: NetApp, Inc.
2011-05-14 18:37:24 +00:00
# bvm console
#
dev/bvm/bvm_console.c optional bvmconsole
dev/bvm/bvm_dbg.c optional bvmdebug
Move the identical x86 lines to files.x86 Move all the identical x86 lines to files.x86. The non-identical ones should be unified and moved as well, but that would require additional changes that would need a more careful review and may not be MFCable, so I'll do them separately. I'll delete the mildly snarky comment when things are unified. Reviewed by: jhb (verbal OK on irc) Differential Revision: https://reviews.freebsd.org/D21248
2019-08-14 20:57:54 +00:00
# Common files where we currently configure the system differently, but perhaps shouldn't
# config(8) doesn't have a way to force standard options, so we've been inconsistent
# about marking non-optional things 'standard'.
Move the MADT parser for amd64 and i386 to sys/x86/acpica now that it is identical on both platforms.
2010-11-08 20:57:02 +00:00
x86/acpica/madt.c optional acpi
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 14:13:39 +00:00
x86/isa/atpic.c optional atpic isa
Allow a native i386 kernel to be built with 'nodevice atpic'. Just as on amd64, if 'device isa' is present quiesce the 8259A's during boot and resume from suspend. While here, be more selective on amd64 about which kernel configurations need elcr.c. MFC after: 2 weeks
2012-03-09 19:42:48 +00:00
x86/isa/elcr.c optional atpic isa | mptable
Introduce the new kernel sub-tree x86 which should contain all the code shared and generalized between our current amd64, i386 and pc98. This is just an initial step that should lead to a more complete effort. For the moment, a very simple porting of cpufreq modules, BIOS calls and the whole MD specific ISA bus part is added to the sub-tree but ideally a lot of code might be added and more shared support should grow. Sponsored by: Sandvine Incorporated Reviewed by: emaste, kib, jhb, imp Discussed on: arch MFC: 3 weeks
2010-02-25 14:13:39 +00:00
x86/isa/isa.c standard
x86/isa/isa_dma.c standard
Add pci_early function to detect Intel stolen memory. On some Intel devices BIOS does not properly reserve memory (called "stolen memory") for the GPU. If the stolen memory is claimed by the OS, functions that depend on stolen memory (like frame buffer compression) can't be used. A function called pci_early_quirks that is called before the virtual memory system is started was added. In Linux, this PCI early quirks function iterates through all PCI slots to check for any device that require quirks. While this more generic solution is preferable I only ported the Intel graphics specific parts because I think my implementation would be too similar to Linux GPL'd solution after looking at the Linux code too much. The code regarding Intel graphics stolen memory was ported from Linux. In the case of Intel graphics stolen memory this pci_early_quirks will read the stolen memory base and size from north bridge registers. The values are stored in global variables that is later read by linuxkpi_gplv2. Linuxkpi stores these values in a Linux-specific structure that is read by the drm driver. Relevant linuxkpi code is here: https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.16/linuxkpi/gplv2/src/linux_compat.c#L37 For now, only amd64 arch is suppor ted since that is the only arch supported by the new drm drivers. I was told that Intel GPUs are always located on 0:2:0 so these values are hard coded for now. Note that the structure and early execution of the detection code is not required in its current form, but we expect that the code will be added shortly which fixes the potential BIOS bugs by reserving the stolen range in phys_avail[]. This must be done as early as possible to avoid conflicts with the potential usage of the memory in kernel. Submitted by: Johannes Lundberg <johalun0@gmail.com> Reviewed by: bwidawsk, imp MFC after: 1 week Differential revision: https://reviews.freebsd.org/D16719 Differential revision: https://reviews.freebsd.org/D17775
2018-10-31 23:17:00 +00:00
x86/pci/pci_early_quirks.c optional pci
Move the I/O APIC code to the x86 tree since it is identical on i386 and amd64.
2010-06-08 17:51:21 +00:00
x86/x86/io_apic.c standard
x86/x86/local_apic.c standard
Merge the mptable support from MD bits to x86 subtree. Sponsored by: Sandvine Incorporated Discussed with: jhb
2010-10-28 07:58:06 +00:00
x86/x86/mptable.c optional mptable
x86/x86/mptable_pci.c optional mptable pci
Move the MD support for PCI message signalled interrupts to the x86 tree as it is identical for i386 and amd64.
2010-06-08 18:36:03 +00:00
x86/x86/msi.c optional pci
xen: add PV/PVH kernel entry point Add the PV/PVH entry point and the low level functions for PVH early initialization. Approved by: gibbs Sponsored by: Citrix Systems R&D amd64/amd64/genassym.c: - Add __FreeBSD_version define to assym.s so it can be used for the Xen notes. amd64/amd64/locore.S: - Make bootstack global so it can be used from Xen kernel entry point. amd64/amd64/xen-locore.S: - Add Xen notes to the kernel. - Add the Xen PV entry point, that is going to call hammer_time_xen. amd64/include/asmacros.h: - Add ELFNOTE macros. i386/xen/xen_machdep.c: - Define HYPERVISOR_start_info for the XEN i386 PV port, which is going to be used in some shared code between PV and PVH. x86/xen/hvm.c: - Define HYPERVISOR_start_info for the PVH port. x86/xen/pv.c: - Introduce hammer_time_xen which is going to perform early setup for Xen PVH: - Setup shared Xen variables start_info, shared_info and xen_store. - Set guest type. - Create initial page tables as FreeBSD expects to find them. - Call into native init function (hammer_time). xen/xen-os.h: - Declare HYPERVISOR_start_info. conf/files.amd64: - Add amd64/amd64/locore.S and x86/xen/pv.c to the list of files.
2014-03-11 10:07:01 +00:00
x86/xen/pv.c optional xenhvm
xen: add an apic_enumerator for PVH On PVH there's no ACPI, so the CPU enumeration must be implemented using Xen hypercalls. Approved by: gibbs Sponsored by: Citrix Systems R&D x86/xen/pvcpu_enum.c: - Enumerate avaiable vCPUs on PVH by using the VCPUOP_is_up hypercall. - Set vcpu_id for PVH guests. conf/files.amd64: - Include the PV CPU enumerator in the XENHVM build.
2014-03-11 10:25:08 +00:00
x86/xen/pvcpu_enum.c optional xenhvm
xen: create a new PCI bus override When running as a Xen PVH Dom0 we need to add custom buses that override some of the functionality present in the ACPI PCI Bus and the PCI Bus. We currently override the ACPI PCI Bus, but not the PCI Bus, so add a new override for the PCI Bus and share the generic functions between them. Reported by: David P. Discher <dpd@dpdtech.com> Sponsored by: Citrix Systems R&D conf/files.amd64: - Add the new files. x86/xen/xen_pci_bus.c: - Generic file that contains the PCI overrides so they can be used by the several PCI specific buses. xen/xen_pci.h: - Prototypes for the generic overried functions. dev/xen/pci/xen_pci.c: - Xen specific override for the PCI bus. dev/xen/pci/xen_acpi_pci.c: - Xen specific override for the ACPI PCI bus.
2014-12-09 18:03:25 +00:00
x86/xen/xen_pci_bus.c optional xenhvm
Merge OpenZFS support in to HEAD. The primary benefit is maintaining a completely shared code base with the community allowing FreeBSD to receive new features sooner and with less effort. I would advise against doing 'zpool upgrade' or creating indispensable pools using new features until this change has had a month+ to soak. Work on merging FreeBSD support in to what was at the time "ZFS on Linux" began in August 2018. I first publicly proposed transitioning FreeBSD to (new) OpenZFS on December 18th, 2018. FreeBSD support in OpenZFS was finally completed in December 2019. A CFT for downstreaming OpenZFS support in to FreeBSD was first issued on July 8th. All issues that were reported have been addressed or, for a couple of less critical matters there are pull requests in progress with OpenZFS. iXsystems has tested and dogfooded extensively internally. The TrueNAS 12 release is based on OpenZFS with some additional features that have not yet made it upstream. Improvements include: project quotas, encrypted datasets, allocation classes, vectorized raidz, vectorized checksums, various command line improvements, zstd compression. Thanks to those who have helped along the way: Ryan Moeller, Allan Jude, Zack Welch, and many others. Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D25872
2020-08-25 02:21:27 +00:00
contrib/openzfs/module/zcommon/zfs_fletcher_avx512.c optional zfs compile-with "${ZFS_C}"
contrib/openzfs/module/zcommon/zfs_fletcher_intel.c optional zfs compile-with "${ZFS_C}"
contrib/openzfs/module/zcommon/zfs_fletcher_sse.c optional zfs compile-with "${ZFS_C}"
contrib/openzfs/module/zfs/vdev_raidz_math_avx2.c optional zfs compile-with "${ZFS_C}"
contrib/openzfs/module/zfs/vdev_raidz_math_avx512bw.c optional zfs compile-with "${ZFS_C}"
contrib/openzfs/module/zfs/vdev_raidz_math_avx512f.c optional zfs compile-with "${ZFS_C}"
contrib/openzfs/module/zfs/vdev_raidz_math_sse2.c optional zfs compile-with "${ZFS_C}"
contrib/openzfs/module/zfs/vdev_raidz_math_ssse3.c optional zfs compile-with "${ZFS_C}"
Reference in New Issue Copy Permalink