freebsd-dev/sys/conf/NOTES

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

2805 lines
98 KiB
Plaintext
Raw Normal View History

#
# NOTES -- Lines that can be cut/pasted into kernel and hints configs.
#
Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others
2000-06-13 22:28:50 +00:00
# Lines that begin with 'device', 'options', 'machine', 'ident', 'maxusers',
# 'makeoptions', 'hints', etc. go into the kernel configuration that you
Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others
2000-06-13 22:28:50 +00:00
# run config(8) with.
#
# Lines that begin with 'envvar hint.' should go into your hints file.
# See /boot/device.hints and/or the 'hints' config(8) directive.
#
# Please use ``make LINT'' to create an old-style LINT file if you want to
# do kernel test-builds.
#
# This file contains machine independent kernel configuration notes. For
# machine dependent notes, look in /sys/<arch>/conf/NOTES.
#
#
# NOTES conventions and style guide:
#
# Large block comments should begin and end with a line containing only a
# comment character.
#
# To describe a particular object, a block comment (if it exists) should
# come first. Next should come device, options, and hints lines in that
# order. All device and option lines must be described by a comment that
# doesn't just expand the device or option name. Use only a concise
# comment on the same line if possible. Very detailed descriptions of
# devices and subsystems belong in man pages.
#
# A space followed by a tab separates 'options' from an option name. Two
# spaces followed by a tab separate 'device' from a device name. Comments
# after an option or device should use one space after the comment character.
# To comment out a negative option that disables code and thus should not be
# enabled for LINT builds, precede 'options' with "#!".
#
#
# This is the ``identification'' of the kernel. Usually this should
# be the same as the name of your kernel.
#
ident LINT
#
# The `maxusers' parameter controls the static sizing of a number of
# internal system tables by a formula defined in subr_param.c.
# Omitting this parameter or setting it to 0 will cause the system to
# auto-size based on physical memory.
#
maxusers 10
# To statically compile in device wiring instead of /boot/device.hints
#hints "LINT.hints" # Default places to look for devices.
# Use the following to compile in values accessible to the kernel
# through getenv() (or kenv(1) in userland). The format of the file
# is 'variable=value', see kenv(1)
#
#env "LINT.env"
#
# The `makeoptions' parameter allows variables to be passed to the
# generated Makefile in the build area.
#
# CONF_CFLAGS gives some extra compiler flags that are added to ${CFLAGS}
# after most other flags. Here we use it to inhibit use of non-optimal
2006-08-24 08:00:02 +00:00
# gcc built-in functions (e.g., memcmp).
#
# DEBUG happens to be magic.
# The following is equivalent to 'config -g KERNELNAME' and creates
# 'kernel.debug' compiled with -g debugging as well as a normal
# 'kernel'. Use 'make install.debug' to install the debug kernel
# but that isn't normally necessary as the debug symbols are not loaded
# by the kernel and are not useful there anyway.
#
# KERNEL can be overridden so that you can change the default name of your
# kernel.
#
2001-10-18 19:44:13 +00:00
# MODULES_OVERRIDE can be used to limit modules built to a specific list.
#
makeoptions CONF_CFLAGS=-fno-builtin #Don't allow use of memcmp, etc.
#makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols
#makeoptions KERNEL=foo #Build kernel "foo" and install "/foo"
# Only build ext2fs module plus those parts of the sound system I need.
#makeoptions MODULES_OVERRIDE="ext2fs sound/sound sound/driver/maestro3"
makeoptions DESTDIR=/tmp
#
# FreeBSD processes are subject to certain limits to their consumption
# of system resources. See getrlimit(2) for more details. Each
# resource limit has two values, a "soft" limit and a "hard" limit.
# The soft limits can be modified during normal system operation, but
# the hard limits are set at boot time. Their default values are
# in sys/<arch>/include/vmparam.h. There are two ways to change them:
#
# 1. Set the values at kernel build time. The options below are one
# way to allow that limit to grow to 1GB. They can be increased
# further by changing the parameters:
#
# 2. In /boot/loader.conf, set the tunables kern.maxswzone,
# kern.maxbcache, kern.maxtsiz, kern.dfldsiz, kern.maxdsiz,
# kern.dflssiz, kern.maxssiz and kern.sgrowsiz.
#
# The options in /boot/loader.conf override anything in the kernel
# configuration file. See the function init_param1 in
# sys/kern/subr_param.c for more details.
#
options MAXDSIZ=(1024UL*1024*1024)
options MAXSSIZ=(128UL*1024*1024)
options DFLDSIZ=(1024UL*1024*1024)
#
# BLKDEV_IOSIZE sets the default block size used in user block
2004-06-26 17:19:44 +00:00
# device I/O. Note that this value will be overridden by the label
# when specifying a block device from a label with a non-0
# partition blocksize. The default is PAGE_SIZE.
#
options BLKDEV_IOSIZE=8192
#
# MAXPHYS and DFLTPHYS
#
# These are the maximal and safe 'raw' I/O block device access sizes.
# Reads and writes will be split into MAXPHYS chunks for known good
# devices and DFLTPHYS for the rest. Some applications have better
# performance with larger raw I/O access sizes. Note that certain VM
# parameters are derived from these values and making them too large
2013-10-24 19:32:20 +00:00
# can make an unbootable kernel.
#
# The defaults are 64K and 128K respectively.
options DFLTPHYS=(64*1024)
options MAXPHYS=(128*1024)
1997-01-16 07:43:27 +00:00
# This allows you to actually store this configuration file into
# the kernel binary itself. See config(8) for more details.
1997-01-16 07:43:27 +00:00
#
options INCLUDE_CONFIG_FILE # Include this file in kernel
1997-01-16 07:43:27 +00:00
#
# Compile-time defaults for various boot parameters
#
options BOOTVERBOSE=1
options BOOTHOWTO=RB_MULTIPLE
#
# Compile-time defaults for dmesg boot tagging
#
# Default boot tag; may use 'kern.boot_tag' loader tunable to override. The
# current boot's tag is also exposed via the 'kern.boot_tag' sysctl.
options BOOT_TAG=\"\"
# Maximum boot tag size the kernel's static buffer should accommodate. Maximum
# size for both BOOT_TAG and the assocated tunable.
options BOOT_TAG_SZ=32
options GEOM_BDE # Disk encryption.
options GEOM_CACHE # Disk cache.
options GEOM_CONCAT # Disk concatenation.
options GEOM_ELI # Disk encryption.
options GEOM_GATE # Userland services.
options GEOM_JOURNAL # Journaling.
options GEOM_LABEL # Providers labelization.
options GEOM_LINUX_LVM # Linux LVM2 volumes
options GEOM_MAP # Map based partitioning
options GEOM_MIRROR # Disk mirroring.
options GEOM_MULTIPATH # Disk multipath
options GEOM_NOP # Test class.
options GEOM_PART_APM # Apple partitioning
options GEOM_PART_BSD # BSD disklabel
options GEOM_PART_BSD64 # BSD disklabel64
options GEOM_PART_EBR # Extended Boot Records
options GEOM_PART_GPT # GPT partitioning
options GEOM_PART_LDM # Logical Disk Manager
options GEOM_PART_MBR # MBR partitioning
options GEOM_RAID # Soft RAID functionality.
2004-08-16 06:36:21 +00:00
options GEOM_RAID3 # RAID3 functionality.
options GEOM_SHSEC # Shared secret.
options GEOM_STRIPE # Disk striping.
options GEOM_UZIP # Read-only compressed disks
options GEOM_VINUM # Vinum logical volume manager
options GEOM_VIRSTOR # Virtual storage.
2006-08-24 08:00:02 +00:00
options GEOM_ZERO # Performance testing helper.
2002-03-11 08:27:23 +00:00
#
# The root device and filesystem type can be compiled in;
# this provides a fallback option if the root device cannot
2002-03-17 22:02:05 +00:00
# be correctly guessed by the bootstrap code, or an override if
# the RB_DFLTROOT flag (-r) is specified when booting the kernel.
#
options ROOTDEVNAME=\"ufs:da0s2e\"
2003-01-26 05:35:54 +00:00
#####################################################################
# Scheduler options:
#
# Specifying one of SCHED_4BSD or SCHED_ULE is mandatory. These options
2003-01-26 05:35:54 +00:00
# select which scheduler is compiled in.
#
# SCHED_4BSD is the historical, proven, BSD scheduler. It has a global run
2006-08-24 08:00:02 +00:00
# queue and no CPU affinity which makes it suboptimal for SMP. It has very
2003-01-26 05:35:54 +00:00
# good interactivity and priority selection.
#
# SCHED_ULE provides significant performance advantages over 4BSD on many
# workloads on SMP machines. It supports cpu-affinity, per-cpu runqueues
# and scheduler locks. It also has a stronger notion of interactivity
# which leads to better responsiveness even on uniprocessor machines. This
# is the default scheduler.
2003-01-26 05:35:54 +00:00
#
# SCHED_STATS is a debugging option which keeps some stats in the sysctl
# tree at 'kern.sched.stats' and is useful for debugging scheduling decisions.
#
options SCHED_4BSD
options SCHED_STATS
#options SCHED_ULE
#####################################################################
# SMP OPTIONS:
#
# SMP enables building of a Symmetric MultiProcessor Kernel.
# Mandatory:
options SMP # Symmetric MultiProcessor Kernel
Add an EARLY_AP_STARTUP option to start APs earlier during boot. Currently, Application Processors (non-boot CPUs) are started by MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until SI_SUB_SMP at which point they are released to run kernel threads. SI_SUB_SMP is one of the last SYSINIT levels, so APs don't enter the scheduler and start running threads until fairly late in the boot. This change moves SI_SUB_SMP up to just before software interrupt threads are created allowing the APs to start executing kernel threads much sooner (before any devices are probed). This allows several initialization routines that need to perform initialization on all CPUs to now perform that initialization in one step rather than having to defer the AP initialization to a second SYSINIT run at SI_SUB_SMP. It also permits all CPUs to be available for handling interrupts before any devices are probed. This last feature fixes a problem on with interrupt vector exhaustion. Specifically, in the old model all device interrupts were routed onto the boot CPU during boot. Later after the APs were released at SI_SUB_SMP, interrupts were redistributed across all CPUs. However, several drivers for multiqueue hardware allocate N interrupts per CPU in the system. In a system with many CPUs, just a few drivers doing this could exhaust the available pool of interrupt vectors on the boot CPU as each driver was allocating N * mp_ncpu vectors on the boot CPU. Now, drivers will allocate interrupts on their desired CPUs during boot meaning that only N interrupts are allocated from the boot CPU instead of N * mp_ncpu. Some other bits of code can also be simplified as smp_started is now true much earlier and will now always be true for these bits of code. This removes the need to treat the single-CPU boot environment as a special case. As a transition aid, the new behavior is available under a new kernel option (EARLY_AP_STARTUP). This will allow the option to be turned off if need be during initial testing. I plan to enable this on x86 by default in a followup commit in the next few days and to have all platforms moved over before 11.0. Once the transition is complete, the option will be removed along with the !EARLY_AP_STARTUP code. These changes have only been tested on x86. Other platform maintainers are encouraged to port their architectures over as well. The main things to check for are any uses of smp_started in MD code that can be simplified and SI_SUB_SMP SYSINITs in MD code that can be removed in the EARLY_AP_STARTUP case (e.g. the interrupt shuffling). PR: kern/199321 Reviewed by: markj, gnn, kib Sponsored by: Netflix
2016-05-14 18:22:52 +00:00
# EARLY_AP_STARTUP releases the Application Processors earlier in the
# kernel startup process (before devices are probed) rather than at the
# end. This is a temporary option for use during the transition from
# late to early AP startup.
options EARLY_AP_STARTUP
Add an EARLY_AP_STARTUP option to start APs earlier during boot. Currently, Application Processors (non-boot CPUs) are started by MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until SI_SUB_SMP at which point they are released to run kernel threads. SI_SUB_SMP is one of the last SYSINIT levels, so APs don't enter the scheduler and start running threads until fairly late in the boot. This change moves SI_SUB_SMP up to just before software interrupt threads are created allowing the APs to start executing kernel threads much sooner (before any devices are probed). This allows several initialization routines that need to perform initialization on all CPUs to now perform that initialization in one step rather than having to defer the AP initialization to a second SYSINIT run at SI_SUB_SMP. It also permits all CPUs to be available for handling interrupts before any devices are probed. This last feature fixes a problem on with interrupt vector exhaustion. Specifically, in the old model all device interrupts were routed onto the boot CPU during boot. Later after the APs were released at SI_SUB_SMP, interrupts were redistributed across all CPUs. However, several drivers for multiqueue hardware allocate N interrupts per CPU in the system. In a system with many CPUs, just a few drivers doing this could exhaust the available pool of interrupt vectors on the boot CPU as each driver was allocating N * mp_ncpu vectors on the boot CPU. Now, drivers will allocate interrupts on their desired CPUs during boot meaning that only N interrupts are allocated from the boot CPU instead of N * mp_ncpu. Some other bits of code can also be simplified as smp_started is now true much earlier and will now always be true for these bits of code. This removes the need to treat the single-CPU boot environment as a special case. As a transition aid, the new behavior is available under a new kernel option (EARLY_AP_STARTUP). This will allow the option to be turned off if need be during initial testing. I plan to enable this on x86 by default in a followup commit in the next few days and to have all platforms moved over before 11.0. Once the transition is complete, the option will be removed along with the !EARLY_AP_STARTUP code. These changes have only been tested on x86. Other platform maintainers are encouraged to port their architectures over as well. The main things to check for are any uses of smp_started in MD code that can be simplified and SI_SUB_SMP SYSINITs in MD code that can be removed in the EARLY_AP_STARTUP case (e.g. the interrupt shuffling). PR: kern/199321 Reviewed by: markj, gnn, kib Sponsored by: Netflix
2016-05-14 18:22:52 +00:00
# MAXCPU defines the maximum number of CPUs that can boot in the system.
# A default value should be already present, for every architecture.
options MAXCPU=32
# NUMA enables use of Non-Uniform Memory Access policies in various kernel
# subsystems.
options NUMA
# MAXMEMDOM defines the maximum number of memory domains that can boot in the
# system. A default value should already be defined by every architecture.
options MAXMEMDOM=2
# ADAPTIVE_MUTEXES changes the behavior of blocking mutexes to spin
# if the thread that currently owns the mutex is executing on another
# CPU. This behavior is enabled by default, so this option can be used
# to disable it.
options NO_ADAPTIVE_MUTEXES
# ADAPTIVE_RWLOCKS changes the behavior of reader/writer locks to spin
# if the thread that currently owns the rwlock is executing on another
# CPU. This behavior is enabled by default, so this option can be used
# to disable it.
options NO_ADAPTIVE_RWLOCKS
# ADAPTIVE_SX changes the behavior of sx locks to spin if the thread that
# currently owns the sx lock is executing on another CPU.
# This behavior is enabled by default, so this option can be used to
# disable it.
options NO_ADAPTIVE_SX
# MUTEX_NOINLINE forces mutex operations to call functions to perform each
# operation rather than inlining the simple cases. This can be used to
# shrink the size of the kernel text segment. Note that this behavior is
# already implied by the INVARIANT_SUPPORT, INVARIANTS, KTR, LOCK_PROFILING,
# and WITNESS options.
options MUTEX_NOINLINE
2006-01-31 22:56:44 +00:00
# RWLOCK_NOINLINE forces rwlock operations to call functions to perform each
# operation rather than inlining the simple cases. This can be used to
# shrink the size of the kernel text segment. Note that this behavior is
# already implied by the INVARIANT_SUPPORT, INVARIANTS, KTR, LOCK_PROFILING,
2006-01-31 22:56:44 +00:00
# and WITNESS options.
options RWLOCK_NOINLINE
# SX_NOINLINE forces sx lock operations to call functions to perform each
# operation rather than inlining the simple cases. This can be used to
# shrink the size of the kernel text segment. Note that this behavior is
# already implied by the INVARIANT_SUPPORT, INVARIANTS, KTR, LOCK_PROFILING,
# and WITNESS options.
options SX_NOINLINE
# SMP Debugging Options:
#
# CALLOUT_PROFILING enables rudimentary profiling of the callwheel data
# structure used as backend in callout(9).
# PREEMPTION allows the threads that are in the kernel to be preempted by
# higher priority [interrupt] threads. It helps with interactivity
# and allows interrupt threads to run sooner rather than waiting.
Implement preemption of kernel threads natively in the scheduler rather than as one-off hacks in various other parts of the kernel: - Add a function maybe_preempt() that is called from sched_add() to determine if a thread about to be added to a run queue should be preempted to directly. If it is not safe to preempt or if the new thread does not have a high enough priority, then the function returns false and sched_add() adds the thread to the run queue. If the thread should be preempted to but the current thread is in a nested critical section, then the flag TDF_OWEPREEMPT is set and the thread is added to the run queue. Otherwise, mi_switch() is called immediately and the thread is never added to the run queue since it is switch to directly. When exiting an outermost critical section, if TDF_OWEPREEMPT is set, then clear it and call mi_switch() to perform the deferred preemption. - Remove explicit preemption from ithread_schedule() as calling setrunqueue() now does all the correct work. This also removes the do_switch argument from ithread_schedule(). - Do not use the manual preemption code in mtx_unlock if the architecture supports native preemption. - Don't call mi_switch() in a loop during shutdown to give ithreads a chance to run if the architecture supports native preemption since the ithreads will just preempt DELAY(). - Don't call mi_switch() from the page zeroing idle thread for architectures that support native preemption as it is unnecessary. - Native preemption is enabled on the same archs that supported ithread preemption, namely alpha, i386, and amd64. This change should largely be a NOP for the default case as committed except that we will do fewer context switches in a few cases and will avoid the run queues completely when preempting. Approved by: scottl (with his re@ hat)
2004-07-02 20:21:44 +00:00
# FULL_PREEMPTION instructs the kernel to preempt non-realtime kernel
2004-09-12 12:13:29 +00:00
# threads. Its sole use is to expose race conditions and other
Implement preemption of kernel threads natively in the scheduler rather than as one-off hacks in various other parts of the kernel: - Add a function maybe_preempt() that is called from sched_add() to determine if a thread about to be added to a run queue should be preempted to directly. If it is not safe to preempt or if the new thread does not have a high enough priority, then the function returns false and sched_add() adds the thread to the run queue. If the thread should be preempted to but the current thread is in a nested critical section, then the flag TDF_OWEPREEMPT is set and the thread is added to the run queue. Otherwise, mi_switch() is called immediately and the thread is never added to the run queue since it is switch to directly. When exiting an outermost critical section, if TDF_OWEPREEMPT is set, then clear it and call mi_switch() to perform the deferred preemption. - Remove explicit preemption from ithread_schedule() as calling setrunqueue() now does all the correct work. This also removes the do_switch argument from ithread_schedule(). - Do not use the manual preemption code in mtx_unlock if the architecture supports native preemption. - Don't call mi_switch() in a loop during shutdown to give ithreads a chance to run if the architecture supports native preemption since the ithreads will just preempt DELAY(). - Don't call mi_switch() from the page zeroing idle thread for architectures that support native preemption as it is unnecessary. - Native preemption is enabled on the same archs that supported ithread preemption, namely alpha, i386, and amd64. This change should largely be a NOP for the default case as committed except that we will do fewer context switches in a few cases and will avoid the run queues completely when preempting. Approved by: scottl (with his re@ hat)
2004-07-02 20:21:44 +00:00
# bugs during development. Enabling this option will reduce
# performance and increase the frequency of kernel panics by
# design. If you aren't sure that you need it then you don't.
# Relies on the PREEMPTION option. DON'T TURN THIS ON.
# SLEEPQUEUE_PROFILING enables rudimentary profiling of the hash table
# used to hold active sleep queues as well as sleep wait message
# frequency.
# TURNSTILE_PROFILING enables rudimentary profiling of the hash table
# used to hold active lock queues.
# UMTX_PROFILING enables rudimentary profiling of the hash table used
# to hold active lock queues.
# WITNESS enables the witness code which detects deadlocks and cycles
# during locking operations.
# WITNESS_KDB causes the witness code to drop into the kernel debugger if
2004-06-26 17:19:44 +00:00
# a lock hierarchy violation occurs or if locks are held when going to
# sleep.
# WITNESS_SKIPSPIN disables the witness checks on spin mutexes.
options PREEMPTION
Implement preemption of kernel threads natively in the scheduler rather than as one-off hacks in various other parts of the kernel: - Add a function maybe_preempt() that is called from sched_add() to determine if a thread about to be added to a run queue should be preempted to directly. If it is not safe to preempt or if the new thread does not have a high enough priority, then the function returns false and sched_add() adds the thread to the run queue. If the thread should be preempted to but the current thread is in a nested critical section, then the flag TDF_OWEPREEMPT is set and the thread is added to the run queue. Otherwise, mi_switch() is called immediately and the thread is never added to the run queue since it is switch to directly. When exiting an outermost critical section, if TDF_OWEPREEMPT is set, then clear it and call mi_switch() to perform the deferred preemption. - Remove explicit preemption from ithread_schedule() as calling setrunqueue() now does all the correct work. This also removes the do_switch argument from ithread_schedule(). - Do not use the manual preemption code in mtx_unlock if the architecture supports native preemption. - Don't call mi_switch() in a loop during shutdown to give ithreads a chance to run if the architecture supports native preemption since the ithreads will just preempt DELAY(). - Don't call mi_switch() from the page zeroing idle thread for architectures that support native preemption as it is unnecessary. - Native preemption is enabled on the same archs that supported ithread preemption, namely alpha, i386, and amd64. This change should largely be a NOP for the default case as committed except that we will do fewer context switches in a few cases and will avoid the run queues completely when preempting. Approved by: scottl (with his re@ hat)
2004-07-02 20:21:44 +00:00
options FULL_PREEMPTION
options WITNESS
options WITNESS_KDB
options WITNESS_SKIPSPIN
# LOCK_PROFILING - Profiling locks. See LOCK_PROFILING(9) for details.
2006-11-11 05:35:39 +00:00
options LOCK_PROFILING
# Set the number of buffers and the hash size. The hash size MUST be larger
# than the number of buffers. Hash size should be prime.
2004-09-03 06:32:11 +00:00
options MPROF_BUFFERS="1536"
options MPROF_HASH_SIZE="1543"
# Profiling for the callout(9) backend.
options CALLOUT_PROFILING
# Profiling for internal hash tables.
options SLEEPQUEUE_PROFILING
options TURNSTILE_PROFILING
options UMTX_PROFILING
# Debugging traces for epoch(9) misuse
options EPOCH_TRACE
#####################################################################
2004-01-25 12:32:56 +00:00
# COMPATIBILITY OPTIONS
# Old tty interface.
options COMPAT_43TTY
# Note that as a general rule, COMPAT_FREEBSD<n> depends on
# COMPAT_FREEBSD<n+1>, COMPAT_FREEBSD<n+2>, etc.
# Enable FreeBSD4 compatibility syscalls
options COMPAT_FREEBSD4
# Enable FreeBSD5 compatibility syscalls
options COMPAT_FREEBSD5
2006-09-26 12:36:34 +00:00
# Enable FreeBSD6 compatibility syscalls
options COMPAT_FREEBSD6
# Enable FreeBSD7 compatibility syscalls
options COMPAT_FREEBSD7
# Enable FreeBSD9 compatibility syscalls
options COMPAT_FREEBSD9
# Enable FreeBSD10 compatibility syscalls
options COMPAT_FREEBSD10
# Enable FreeBSD11 compatibility syscalls
options COMPAT_FREEBSD11
# Enable FreeBSD12 compatibility syscalls
options COMPAT_FREEBSD12
# Enable FreeBSD13 compatibility syscalls
options COMPAT_FREEBSD13
# Enable Linux Kernel Programming Interface
options COMPAT_LINUXKPI
#
# These three options provide support for System V Interface
# Definition-style interprocess communication, in the form of shared
# memory, semaphores, and message queues, respectively.
#
options SYSVSHM
options SYSVSEM
options SYSVMSG
#####################################################################
# DEBUGGING OPTIONS
#
# Compile with kernel debugger related code.
#
options KDB
Load the kernel symbol table in the boot loader and not at compile time. (Boot with the -D flag if you want symbols.) Make it easier to extend `struct bootinfo' without losing either forwards or backwards compatibility. ddb_aout.c: Get the symbol table from wherever the loader put it. Nuke db_symtab[SYMTAB_SPACE]. boot.c: Enable loading of symbols. Align them on a page boundary. Add printfs about the symbol table sizes. Pass the memory sizes to the kernel. Fix initialization of `unit' (it got moved out of the loop). Fix adding the bss size (it got moved inside an ifdef). Initialize serial port when RB_SERIAL is toggled on. Fix comments. Clean up formatting of recently added code. io.c: Clean up formatting of recently added code. netboot/main.c, machdep.c, wd.c: Change names of bootinfo fields. LINT: Nuke SYMTAB_SPACE. Fix comment about DODUMP. Makefile.i386: Nuke use of dbsym. Exclude gcc symbols from kernel unless compiling with -g. Remove unused macro. Fix comments and formatting. genassym.c: Generate defines for some new bootinfo fields. Change names of old ones. locore.s: Copy only the valid part of the `struct bootinfo' passed by the loader. Reserve space for symbol table, if any. machdep.c: Check the memory sizes passed by the loader, if any. Don't use them yet. bootinfo.h: Add a size field so that we can resolve some mismatches between the loader bootinfo and the kernel boot info. The version number is not so good for this because of historical botches and because it's harder to maintain. Add memory size and symbol table fields. Change the names of everything. Hacks to save a few bytes: asm.S, boot.c, boot2.S: Replace `ouraddr' by `(BOOTSEG << 4)'. boot.c: Don't statically initialize `loadflags' to 0. Disable the "REDUNDANT" code that skips the BIOS variables. Eliminate `total'. Combine some more printfs. boot.h, disk.c, io.c, table.c: Move all statically initialzed data to table.c. io.c: Don't put the A20 gate bits in a variable.
1995-01-25 21:40:47 +00:00
#
# Print a stack trace of the current thread on the console for a panic.
#
options KDB_TRACE
#
# Don't enter the debugger for a panic. Intended for unattended operation
# where you may want to enter the debugger from the console, but still want
# the machine to recover from a panic.
#
options KDB_UNATTENDED
#
# Enable the ddb debugger backend.
#
options DDB
#
# Print the numerical value of symbols in addition to the symbolic
# representation.
#
options DDB_NUMSYM
#
# Enable the remote gdb debugger backend.
#
options GDB
#
# Trashes list pointers when they become invalid (i.e., the element is
# removed from a list). Relatively inexpensive to enable.
#
options QUEUE_MACRO_DEBUG_TRASH
#
# Stores information about the last caller to modify the list object
# in the list object. Requires additional memory overhead.
#
#options QUEUE_MACRO_DEBUG_TRACE
#
# SYSCTL_DEBUG enables a 'sysctl' debug tree that can be used to dump the
# contents of the registered sysctl nodes on the console. It is disabled by
2006-08-24 08:00:02 +00:00
# default because it generates excessively verbose console output that can
# interfere with serial console operation.
#
options SYSCTL_DEBUG
#
# Enable textdump by default, this disables kernel core dumps.
#
options TEXTDUMP_PREFERRED
#
# Enable extra debug messages while performing textdumps.
#
options TEXTDUMP_VERBOSE
#
# NO_SYSCTL_DESCR omits the sysctl node descriptions to save space in the
# resulting kernel.
options NO_SYSCTL_DESCR
#
# MALLOC_DEBUG_MAXZONES enables multiple uma zones for malloc(9)
# allocations that are smaller than a page. The purpose is to isolate
# different malloc types into hash classes, so that any buffer
# overruns or use-after-free will usually only affect memory from
# malloc types in that hash class. This is purely a debugging tool;
# by varying the hash function and tracking which hash class was
# corrupted, the intersection of the hash classes from each instance
# will point to a single malloc type that is being misused. At this
# point inspection or memguard(9) can be used to catch the offending
# code.
#
options MALLOC_DEBUG_MAXZONES=8
#
# DEBUG_MEMGUARD builds and enables memguard(9), a replacement allocator
# for the kernel used to detect modify-after-free scenarios. See the
# memguard(9) man page for more information on usage.
#
options DEBUG_MEMGUARD
#
# DEBUG_REDZONE enables buffer underflows and buffer overflows detection for
# malloc(9).
#
options DEBUG_REDZONE
2014-01-22 22:25:48 +00:00
#
# EARLY_PRINTF enables support for calling a special printf (eprintf)
# very early in the kernel (before cn_init() has been called). This
# should only be used for debugging purposes early in boot. Normally,
# it is not defined. It is commented out here because this feature
# isn't generally available. And the required eputc() isn't defined.
#
#options EARLY_PRINTF
2014-01-22 22:25:48 +00:00
#
Overhaul the ktrace subsystem a bit. For the most part, the actual vnode operations to dump a ktrace event out to an output file are now handled asychronously by a ktrace worker thread. This enables most ktrace events to not need Giant once p_tracep and p_traceflag are suitably protected by the new ktrace_lock. There is a single todo list of pending ktrace requests. The various ktrace tracepoints allocate a ktrace request object and tack it onto the end of the queue. The ktrace kernel thread grabs requests off the head of the queue and processes them using the trace vnode and credentials of the thread triggering the event. Since we cannot assume that the user memory referenced when doing a ktrgenio() will be valid and since we can't access it from the ktrace worker thread without a bit of hassle anyways, ktrgenio() requests are still handled synchronously. However, in order to ensure that the requests from a given thread still maintain relative order to one another, when a synchronous ktrace event (such as a genio event) is triggered, we still put the request object on the todo list to synchronize with the worker thread. The original thread blocks atomically with putting the item on the queue. When the worker thread comes across an asynchronous request, it wakes up the original thread and then blocks to ensure it doesn't manage to write a later event before the original thread has a chance to write out the synchronous event. When the original thread wakes up, it writes out the synchronous using its own context and then finally wakes the worker thread back up. Yuck. The sychronous events aren't pretty but they do work. Since ktrace events can be triggered in fairly low-level areas (msleep() and cv_wait() for example) the ktrace code is designed to use very few locks when posting an event (currently just the ktrace_mtx lock and the vnode interlock to bump the refcoun on the trace vnode). This also means that we can't allocate a ktrace request object when an event is triggered. Instead, ktrace request objects are allocated from a pre-allocated pool and returned to the pool after a request is serviced. The size of this pool defaults to 100 objects, which is about 13k on an i386 kernel. The size of the pool can be adjusted at compile time via the KTRACE_REQUEST_POOL kernel option, at boot time via the kern.ktrace_request_pool loader tunable, or at runtime via the kern.ktrace_request_pool sysctl. If the pool of request objects is exhausted, then a warning message is printed to the console. The message is rate-limited in that it is only printed once until the size of the pool is adjusted via the sysctl. I have tested all kernel traces but have not tested user traces submitted by utrace(2), though they should work fine in theory. Since a ktrace request has several properties (content of event, trace vnode, details of originating process, credentials for I/O, etc.), I chose to drop the first argument to the various ktrfoo() functions. Currently the functions just assume the event is posted from curthread. If there is a great desire to do so, I suppose I could instead put back the first argument but this time make it a thread pointer instead of a vnode pointer. Also, KTRPOINT() now takes a thread as its first argument instead of a process. This is because the check for a recursive ktrace event is now per-thread instead of process-wide. Tested on: i386 Compiles on: sparc64, alpha
2002-06-07 05:32:59 +00:00
# KTRACE enables the system-call tracing facility ktrace(2). To be more
# SMP-friendly, KTRACE uses a worker thread to process most trace events
# asynchronously to the thread generating the event. This requires a
# pre-allocated store of objects representing trace events. The
# KTRACE_REQUEST_POOL option specifies the initial size of this store.
# The size of the pool can be adjusted both at boottime and runtime via
# the kern.ktrace_request_pool tunable and sysctl.
#
options KTRACE #kernel tracing
Overhaul the ktrace subsystem a bit. For the most part, the actual vnode operations to dump a ktrace event out to an output file are now handled asychronously by a ktrace worker thread. This enables most ktrace events to not need Giant once p_tracep and p_traceflag are suitably protected by the new ktrace_lock. There is a single todo list of pending ktrace requests. The various ktrace tracepoints allocate a ktrace request object and tack it onto the end of the queue. The ktrace kernel thread grabs requests off the head of the queue and processes them using the trace vnode and credentials of the thread triggering the event. Since we cannot assume that the user memory referenced when doing a ktrgenio() will be valid and since we can't access it from the ktrace worker thread without a bit of hassle anyways, ktrgenio() requests are still handled synchronously. However, in order to ensure that the requests from a given thread still maintain relative order to one another, when a synchronous ktrace event (such as a genio event) is triggered, we still put the request object on the todo list to synchronize with the worker thread. The original thread blocks atomically with putting the item on the queue. When the worker thread comes across an asynchronous request, it wakes up the original thread and then blocks to ensure it doesn't manage to write a later event before the original thread has a chance to write out the synchronous event. When the original thread wakes up, it writes out the synchronous using its own context and then finally wakes the worker thread back up. Yuck. The sychronous events aren't pretty but they do work. Since ktrace events can be triggered in fairly low-level areas (msleep() and cv_wait() for example) the ktrace code is designed to use very few locks when posting an event (currently just the ktrace_mtx lock and the vnode interlock to bump the refcoun on the trace vnode). This also means that we can't allocate a ktrace request object when an event is triggered. Instead, ktrace request objects are allocated from a pre-allocated pool and returned to the pool after a request is serviced. The size of this pool defaults to 100 objects, which is about 13k on an i386 kernel. The size of the pool can be adjusted at compile time via the KTRACE_REQUEST_POOL kernel option, at boot time via the kern.ktrace_request_pool loader tunable, or at runtime via the kern.ktrace_request_pool sysctl. If the pool of request objects is exhausted, then a warning message is printed to the console. The message is rate-limited in that it is only printed once until the size of the pool is adjusted via the sysctl. I have tested all kernel traces but have not tested user traces submitted by utrace(2), though they should work fine in theory. Since a ktrace request has several properties (content of event, trace vnode, details of originating process, credentials for I/O, etc.), I chose to drop the first argument to the various ktrfoo() functions. Currently the functions just assume the event is posted from curthread. If there is a great desire to do so, I suppose I could instead put back the first argument but this time make it a thread pointer instead of a vnode pointer. Also, KTRPOINT() now takes a thread as its first argument instead of a process. This is because the check for a recursive ktrace event is now per-thread instead of process-wide. Tested on: i386 Compiles on: sparc64, alpha
2002-06-07 05:32:59 +00:00
options KTRACE_REQUEST_POOL=101
#
2009-10-29 09:51:13 +00:00
# KTR is a kernel tracing facility imported from BSD/OS. It is
# enabled with the KTR option. KTR_ENTRIES defines the number of
# entries in the circular trace buffer; it may be an arbitrary number.
# KTR_BOOT_ENTRIES defines the number of entries during the early boot,
# before malloc(9) is functional.
# KTR_COMPILE defines the mask of events to compile into the kernel as
# defined by the KTR_* constants in <sys/ktr.h>. KTR_MASK defines the
# initial value of the ktr_mask variable which determines at runtime
# what events to trace. KTR_CPUMASK determines which CPU's log
# events, with bit X corresponding to CPU X. The layout of the string
# passed as KTR_CPUMASK must match a series of bitmasks each of them
# separated by the "," character (ie:
# KTR_CPUMASK=0xAF,0xFFFFFFFFFFFFFFFF). KTR_VERBOSE enables
# dumping of KTR events to the console by default. This functionality
# can be toggled via the debug.ktr_verbose sysctl and defaults to off
2009-10-29 09:51:13 +00:00
# if KTR_VERBOSE is not defined. See ktr(4) and ktrdump(8) for details.
#
options KTR
options KTR_BOOT_ENTRIES=1024
options KTR_ENTRIES=(128*1024)
options KTR_COMPILE=(KTR_ALL)
options KTR_MASK=KTR_INTR
options KTR_CPUMASK=0x3
2000-11-07 01:50:10 +00:00
options KTR_VERBOSE
#
2006-08-24 08:00:02 +00:00
# ALQ(9) is a facility for the asynchronous queuing of records from the kernel
2009-10-29 09:51:13 +00:00
# to a vnode, and is employed by services such as ktr(4) to produce trace
# files based on a kernel event stream. Records are written asynchronously
# in a worker thread.
#
options ALQ
options KTR_ALQ
#
# The INVARIANTS option is used in a number of source files to enable
# extra sanity checking of internal structures. This support is not
# enabled by default because of the extra time it would take to check
# for these conditions, which can only occur as a result of
# programming errors.
#
options INVARIANTS
#
# The INVARIANT_SUPPORT option makes us compile in support for
# verifying some of the internal structures. It is a prerequisite for
# 'INVARIANTS', as enabling 'INVARIANTS' will make these functions be
# called. The intent is that you can set 'INVARIANTS' for single
# source files (by changing the source file or specifying it on the
# command line) if you have 'INVARIANT_SUPPORT' enabled. Also, if you
# wish to build a kernel module with 'INVARIANTS', then adding
# 'INVARIANT_SUPPORT' to your kernel will provide all the necessary
# infrastructure without the added overhead.
#
options INVARIANT_SUPPORT
#
# The KASSERT_PANIC_OPTIONAL option allows kasserts to fire without
# necessarily inducing a panic. Panic is the default behavior, but
# runtime options can configure it either entirely off, or off with a
# limit.
#
options KASSERT_PANIC_OPTIONAL
#
# The DIAGNOSTIC option is used to enable extra debugging information
# and invariants checking. The added checks are too expensive or noisy
# for an INVARIANTS kernel and thus are disabled by default. It is
# expected that a kernel configured with DIAGNOSTIC will also have the
# INVARIANTS option enabled.
#
options DIAGNOSTIC
#
# REGRESSION causes optional kernel interfaces necessary only for regression
2004-06-26 17:19:44 +00:00
# testing to be enabled. These interfaces may constitute security risks
# when enabled, as they permit processes to easily modify aspects of the
# run-time environment to reproduce unlikely or unusual (possibly normally
# impossible) scenarios.
#
options REGRESSION
#
# This option lets some drivers co-exist that can't co-exist in a running
# system. This is used to be able to compile all kernel code in one go for
# quality assurance purposes (like this file, which the option takes it name
# from.)
#
options COMPILING_LINT
#
# STACK enables the stack(9) facility, allowing the capture of kernel stack
# for the purpose of procinfo(1), etc. stack(9) will also be compiled in
# automatically if DDB(4) is compiled into the kernel.
#
options STACK
#
# The NUM_CORE_FILES option specifies the limit for the number of core
# files generated by a particular process, when the core file format
# specifier includes the %I pattern. Since we only have 1 character for
# the core count in the format string, meaning the range will be 0-9, the
# maximum value allowed for this option is 10.
# This core file limit can be adjusted at runtime via the debug.ncores
# sysctl.
#
options NUM_CORE_FILES=5
#
# The TSLOG option enables timestamped logging of events, especially
# function entries/exits, in order to track the time spent by the kernel.
# In particular, this is useful when investigating the early boot process,
# before it is possible to use more sophisticated tools like DTrace.
# The TSLOGSIZE option controls the size of the (preallocated, fixed
# length) buffer used for storing these events (default: 262144 records).
# The TSLOG_PAGEZERO option enables TSLOG of pmap_zero_page; this must be
# enabled separately since it typically generates too many records to be
# useful.
#
# For security reasons the TSLOG option should not be enabled on systems
# used in production.
#
options TSLOG
options TSLOGSIZE=262144
#####################################################################
# PERFORMANCE MONITORING OPTIONS
#
# The hwpmc driver that allows the use of in-CPU performance monitoring
# counters for performance monitoring. The base kernel needs to be configured
# with the 'options' line, while the hwpmc device can be either compiled
# in or loaded as a loadable kernel module.
#
# Additional configuration options may be required on specific architectures,
# please see hwpmc(4).
device hwpmc # Driver (also a loadable module)
options HWPMC_DEBUG
options HWPMC_HOOKS # Other necessary kernel hooks
#####################################################################
# NETWORKING OPTIONS
#
# Protocol families
#
options INET #Internet communications protocols
options INET6 #IPv6 communications protocols
tcp: Congestion control cleanup. NOTE: HEADS UP read the note below if your kernel config is not including GENERIC!! This patch does a bit of cleanup on TCP congestion control modules. There were some rather interesting surprises that one could get i.e. where you use a socket option to change from one CC (say cc_cubic) to another CC (say cc_vegas) and you could in theory get a memory failure and end up on cc_newreno. This is not what one would expect. The new code fixes this by requiring a cc_data_sz() function so we can malloc with M_WAITOK and pass in to the init function preallocated memory. The CC init is expected in this case *not* to fail but if it does and a module does break the "no fail with memory given" contract we do fall back to the CC that was in place at the time. This also fixes up a set of common newreno utilities that can be shared amongst other CC modules instead of the other CC modules reaching into newreno and executing what they think is a "common and understood" function. Lets put these functions in cc.c and that way we have a common place that is easily findable by future developers or bug fixers. This also allows newreno to evolve and grow support for its features i.e. ABE and HYSTART++ without having to dance through hoops for other CC modules, instead both newreno and the other modules just call into the common functions if they desire that behavior or roll there own if that makes more sense. Note: This commit changes the kernel configuration!! If you are not using GENERIC in some form you must add a CC module option (one of CC_NEWRENO, CC_VEGAS, CC_CUBIC, CC_CDG, CC_CHD, CC_DCTCP, CC_HTCP, CC_HD). You can have more than one defined as well if you desire. Note that if you create a kernel configuration that does not define a congestion control module and includes INET or INET6 the kernel compile will break. Also you need to define a default, generic adds 'options CC_DEFAULT=\"newreno\" but you can specify any string that represents the name of the CC module (same names that show up in the CC module list under net.inet.tcp.cc). If you fail to add the options CC_DEFAULT in your kernel configuration the kernel build will also break. Reviewed by: Michael Tuexen Sponsored by: Netflix Inc. RELNOTES:YES Differential Revision: https://reviews.freebsd.org/D32693
2021-11-11 11:28:18 +00:00
#
# Note if you include INET/INET6 or both options
# You *must* define at least one of the congestion control
# options or the compile will fail. GENERIC defines
# options CC_CUBIC. You may want to specify a default
# if multiple congestion controls are compiled in.
# The string in default is the name of the
tcp: Congestion control cleanup. NOTE: HEADS UP read the note below if your kernel config is not including GENERIC!! This patch does a bit of cleanup on TCP congestion control modules. There were some rather interesting surprises that one could get i.e. where you use a socket option to change from one CC (say cc_cubic) to another CC (say cc_vegas) and you could in theory get a memory failure and end up on cc_newreno. This is not what one would expect. The new code fixes this by requiring a cc_data_sz() function so we can malloc with M_WAITOK and pass in to the init function preallocated memory. The CC init is expected in this case *not* to fail but if it does and a module does break the "no fail with memory given" contract we do fall back to the CC that was in place at the time. This also fixes up a set of common newreno utilities that can be shared amongst other CC modules instead of the other CC modules reaching into newreno and executing what they think is a "common and understood" function. Lets put these functions in cc.c and that way we have a common place that is easily findable by future developers or bug fixers. This also allows newreno to evolve and grow support for its features i.e. ABE and HYSTART++ without having to dance through hoops for other CC modules, instead both newreno and the other modules just call into the common functions if they desire that behavior or roll there own if that makes more sense. Note: This commit changes the kernel configuration!! If you are not using GENERIC in some form you must add a CC module option (one of CC_NEWRENO, CC_VEGAS, CC_CUBIC, CC_CDG, CC_CHD, CC_DCTCP, CC_HTCP, CC_HD). You can have more than one defined as well if you desire. Note that if you create a kernel configuration that does not define a congestion control module and includes INET or INET6 the kernel compile will break. Also you need to define a default, generic adds 'options CC_DEFAULT=\"newreno\" but you can specify any string that represents the name of the CC module (same names that show up in the CC module list under net.inet.tcp.cc). If you fail to add the options CC_DEFAULT in your kernel configuration the kernel build will also break. Reviewed by: Michael Tuexen Sponsored by: Netflix Inc. RELNOTES:YES Differential Revision: https://reviews.freebsd.org/D32693
2021-11-11 11:28:18 +00:00
# cc module as it would appear in the sysctl for
# setting the default. The code defines CUBIC
# as default, or the sole cc_module compiled in.
tcp: Congestion control cleanup. NOTE: HEADS UP read the note below if your kernel config is not including GENERIC!! This patch does a bit of cleanup on TCP congestion control modules. There were some rather interesting surprises that one could get i.e. where you use a socket option to change from one CC (say cc_cubic) to another CC (say cc_vegas) and you could in theory get a memory failure and end up on cc_newreno. This is not what one would expect. The new code fixes this by requiring a cc_data_sz() function so we can malloc with M_WAITOK and pass in to the init function preallocated memory. The CC init is expected in this case *not* to fail but if it does and a module does break the "no fail with memory given" contract we do fall back to the CC that was in place at the time. This also fixes up a set of common newreno utilities that can be shared amongst other CC modules instead of the other CC modules reaching into newreno and executing what they think is a "common and understood" function. Lets put these functions in cc.c and that way we have a common place that is easily findable by future developers or bug fixers. This also allows newreno to evolve and grow support for its features i.e. ABE and HYSTART++ without having to dance through hoops for other CC modules, instead both newreno and the other modules just call into the common functions if they desire that behavior or roll there own if that makes more sense. Note: This commit changes the kernel configuration!! If you are not using GENERIC in some form you must add a CC module option (one of CC_NEWRENO, CC_VEGAS, CC_CUBIC, CC_CDG, CC_CHD, CC_DCTCP, CC_HTCP, CC_HD). You can have more than one defined as well if you desire. Note that if you create a kernel configuration that does not define a congestion control module and includes INET or INET6 the kernel compile will break. Also you need to define a default, generic adds 'options CC_DEFAULT=\"newreno\" but you can specify any string that represents the name of the CC module (same names that show up in the CC module list under net.inet.tcp.cc). If you fail to add the options CC_DEFAULT in your kernel configuration the kernel build will also break. Reviewed by: Michael Tuexen Sponsored by: Netflix Inc. RELNOTES:YES Differential Revision: https://reviews.freebsd.org/D32693
2021-11-11 11:28:18 +00:00
#
options CC_CDG
options CC_CHD
options CC_CUBIC
options CC_DCTCP
options CC_HD
options CC_HTCP
options CC_NEWRENO
options CC_VEGAS
options CC_DEFAULT=\"cubic\"
options RATELIMIT # TX rate limiting support
Implement kernel support for hardware rate limited sockets. - Add RATELIMIT kernel configuration keyword which must be set to enable the new functionality. - Add support for hardware driven, Receive Side Scaling, RSS aware, rate limited sendqueues and expose the functionality through the already established SO_MAX_PACING_RATE setsockopt(). The API support rates in the range from 1 to 4Gbytes/s which are suitable for regular TCP and UDP streams. The setsockopt(2) manual page has been updated. - Add rate limit function callback API to "struct ifnet" which supports the following operations: if_snd_tag_alloc(), if_snd_tag_modify(), if_snd_tag_query() and if_snd_tag_free(). - Add support to ifconfig to view, set and clear the IFCAP_TXRTLMT flag, which tells if a network driver supports rate limiting or not. - This patch also adds support for rate limiting through VLAN and LAGG intermediate network devices. - How rate limiting works: 1) The userspace application calls setsockopt() after accepting or making a new connection to set the rate which is then stored in the socket structure in the kernel. Later on when packets are transmitted a check is made in the transmit path for rate changes. A rate change implies a non-blocking ifp->if_snd_tag_alloc() call will be made to the destination network interface, which then sets up a custom sendqueue with the given rate limitation parameter. A "struct m_snd_tag" pointer is returned which serves as a "snd_tag" hint in the m_pkthdr for the subsequently transmitted mbufs. 2) When the network driver sees the "m->m_pkthdr.snd_tag" different from NULL, it will move the packets into a designated rate limited sendqueue given by the snd_tag pointer. It is up to the individual drivers how the rate limited traffic will be rate limited. 3) Route changes are detected by the NIC drivers in the ifp->if_transmit() routine when the ifnet pointer in the incoming snd_tag mismatches the one of the network interface. The network adapter frees the mbuf and returns EAGAIN which causes the ip_output() to release and clear the send tag. Upon next ip_output() a new "snd_tag" will be tried allocated. 4) When the PCB is detached the custom sendqueue will be released by a non-blocking ifp->if_snd_tag_free() call to the currently bound network interface. Reviewed by: wblock (manpages), adrian, gallatin, scottl (network) Differential Revision: https://reviews.freebsd.org/D3687 Sponsored by: Mellanox Technologies MFC after: 3 months
2017-01-18 13:31:17 +00:00
options ROUTETABLES=2 # allocated fibs up to 65536. default is 1.
# but that would be a bad idea as they are large.
Add code to allow the system to handle multiple routing tables. This particular implementation is designed to be fully backwards compatible and to be MFC-able to 7.x (and 6.x) Currently the only protocol that can make use of the multiple tables is IPv4 Similar functionality exists in OpenBSD and Linux. From my notes: ----- One thing where FreeBSD has been falling behind, and which by chance I have some time to work on is "policy based routing", which allows different packet streams to be routed by more than just the destination address. Constraints: ------------ I want to make some form of this available in the 6.x tree (and by extension 7.x) , but FreeBSD in general needs it so I might as well do it in -current and back port the portions I need. One of the ways that this can be done is to have the ability to instantiate multiple kernel routing tables (which I will now refer to as "Forwarding Information Bases" or "FIBs" for political correctness reasons). Which FIB a particular packet uses to make the next hop decision can be decided by a number of mechanisms. The policies these mechanisms implement are the "Policies" referred to in "Policy based routing". One of the constraints I have if I try to back port this work to 6.x is that it must be implemented as a EXTENSION to the existing ABIs in 6.x so that third party applications do not need to be recompiled in timespan of the branch. This first version will not have some of the bells and whistles that will come with later versions. It will, for example, be limited to 16 tables in the first commit. Implementation method, Compatible version. (part 1) ------------------------------- For this reason I have implemented a "sufficient subset" of a multiple routing table solution in Perforce, and back-ported it to 6.x. (also in Perforce though not always caught up with what I have done in -current/P4). The subset allows a number of FIBs to be defined at compile time (8 is sufficient for my purposes in 6.x) and implements the changes needed to allow IPV4 to use them. I have not done the changes for ipv6 simply because I do not need it, and I do not have enough knowledge of ipv6 (e.g. neighbor discovery) needed to do it. Other protocol families are left untouched and should there be users with proprietary protocol families, they should continue to work and be oblivious to the existence of the extra FIBs. To understand how this is done, one must know that the current FIB code starts everything off with a single dimensional array of pointers to FIB head structures (One per protocol family), each of which in turn points to the trie of routes available to that family. The basic change in the ABI compatible version of the change is to extent that array to be a 2 dimensional array, so that instead of protocol family X looking at rt_tables[X] for the table it needs, it looks at rt_tables[Y][X] when for all protocol families except ipv4 Y is always 0. Code that is unaware of the change always just sees the first row of the table, which of course looks just like the one dimensional array that existed before. The entry points rtrequest(), rtalloc(), rtalloc1(), rtalloc_ign() are all maintained, but refer only to the first row of the array, so that existing callers in proprietary protocols can continue to do the "right thing". Some new entry points are added, for the exclusive use of ipv4 code called in_rtrequest(), in_rtalloc(), in_rtalloc1() and in_rtalloc_ign(), which have an extra argument which refers the code to the correct row. In addition, there are some new entry points (currently called rtalloc_fib() and friends) that check the Address family being looked up and call either rtalloc() (and friends) if the protocol is not IPv4 forcing the action to row 0 or to the appropriate row if it IS IPv4 (and that info is available). These are for calling from code that is not specific to any particular protocol. The way these are implemented would change in the non ABI preserving code to be added later. One feature of the first version of the code is that for ipv4, the interface routes show up automatically on all the FIBs, so that no matter what FIB you select you always have the basic direct attached hosts available to you. (rtinit() does this automatically). You CAN delete an interface route from one FIB should you want to but by default it's there. ARP information is also available in each FIB. It's assumed that the same machine would have the same MAC address, regardless of which FIB you are using to get to it. This brings us as to how the correct FIB is selected for an outgoing IPV4 packet. Firstly, all packets have a FIB associated with them. if nothing has been done to change it, it will be FIB 0. The FIB is changed in the following ways. Packets fall into one of a number of classes. 1/ locally generated packets, coming from a socket/PCB. Such packets select a FIB from a number associated with the socket/PCB. This in turn is inherited from the process, but can be changed by a socket option. The process in turn inherits it on fork. I have written a utility call setfib that acts a bit like nice.. setfib -3 ping target.example.com # will use fib 3 for ping. It is an obvious extension to make it a property of a jail but I have not done so. It can be achieved by combining the setfib and jail commands. 2/ packets received on an interface for forwarding. By default these packets would use table 0, (or possibly a number settable in a sysctl(not yet)). but prior to routing the firewall can inspect them (see below). (possibly in the future you may be able to associate a FIB with packets received on an interface.. An ifconfig arg, but not yet.) 3/ packets inspected by a packet classifier, which can arbitrarily associate a fib with it on a packet by packet basis. A fib assigned to a packet by a packet classifier (such as ipfw) would over-ride a fib associated by a more default source. (such as cases 1 or 2). 4/ a tcp listen socket associated with a fib will generate accept sockets that are associated with that same fib. 5/ Packets generated in response to some other packet (e.g. reset or icmp packets). These should use the FIB associated with the packet being reponded to. 6/ Packets generated during encapsulation. gif, tun and other tunnel interfaces will encapsulate using the FIB that was in effect withthe proces that set up the tunnel. thus setfib 1 ifconfig gif0 [tunnel instructions] will set the fib for the tunnel to use to be fib 1. Routing messages would be associated with their process, and thus select one FIB or another. messages from the kernel would be associated with the fib they refer to and would only be received by a routing socket associated with that fib. (not yet implemented) In addition Netstat has been edited to be able to cope with the fact that the array is now 2 dimensional. (It looks in system memory using libkvm (!)). Old versions of netstat see only the first FIB. In addition two sysctls are added to give: a) the number of FIBs compiled in (active) b) the default FIB of the calling process. Early testing experience: ------------------------- Basically our (IronPort's) appliance does this functionality already using ipfw fwd but that method has some drawbacks. For example, It can't fully simulate a routing table because it can't influence the socket's choice of local address when a connect() is done. Testing during the generating of these changes has been remarkably smooth so far. Multiple tables have co-existed with no notable side effects, and packets have been routes accordingly. ipfw has grown 2 new keywords: setfib N ip from anay to any count ip from any to any fib N In pf there seems to be a requirement to be able to give symbolic names to the fibs but I do not have that capacity. I am not sure if it is required. SCTP has interestingly enough built in support for this, called VRFs in Cisco parlance. it will be interesting to see how that handles it when it suddenly actually does something. Where to next: -------------------- After committing the ABI compatible version and MFCing it, I'd like to proceed in a forward direction in -current. this will result in some roto-tilling in the routing code. Firstly: the current code's idea of having a separate tree per protocol family, all of the same format, and pointed to by the 1 dimensional array is a bit silly. Especially when one considers that there is code that makes assumptions about every protocol having the same internal structures there. Some protocols don't WANT that sort of structure. (for example the whole idea of a netmask is foreign to appletalk). This needs to be made opaque to the external code. My suggested first change is to add routing method pointers to the 'domain' structure, along with information pointing the data. instead of having an array of pointers to uniform structures, there would be an array pointing to the 'domain' structures for each protocol address domain (protocol family), and the methods this reached would be called. The methods would have an argument that gives FIB number, but the protocol would be free to ignore it. When the ABI can be changed it raises the possibilty of the addition of a fib entry into the "struct route". Currently, the structure contains the sockaddr of the desination, and the resulting fib entry. To make this work fully, one could add a fib number so that given an address and a fib, one can find the third element, the fib entry. Interaction with the ARP layer/ LL layer would need to be revisited as well. Qing Li has been working on this already. This work was sponsored by Ironport Systems/Cisco Reviewed by: several including rwatson, bz and mlair (parts each) Obtained from: Ironport systems/Cisco
2008-05-09 23:03:00 +00:00
options TCP_OFFLOAD # TCP offload support.
options TCP_RFC7413 # TCP Fast Open
options TCPHPTS
makeoptions WITH_EXTRA_TCP_STACKS=1 # RACK and BBR TCP kernel modules
2018-06-08 05:48:36 +00:00
# In order to enable IPSEC you MUST also add device crypto to
# your kernel configuration
options IPSEC #IP security (requires device crypto)
Merge projects/ipsec into head/. Small summary ------------- o Almost all IPsec releated code was moved into sys/netipsec. o New kernel modules added: ipsec.ko and tcpmd5.ko. New kernel option IPSEC_SUPPORT added. It enables support for loading and unloading of ipsec.ko and tcpmd5.ko kernel modules. o IPSEC_NAT_T option was removed. Now NAT-T support is enabled by default. The UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type support was removed. Added TCP/UDP checksum handling for inbound packets that were decapsulated by transport mode SAs. setkey(8) modified to show run-time NAT-T configuration of SA. o New network pseudo interface if_ipsec(4) added. For now it is build as part of ipsec.ko module (or with IPSEC kernel). It implements IPsec virtual tunnels to create route-based VPNs. o The network stack now invokes IPsec functions using special methods. The only one header file <netipsec/ipsec_support.h> should be included to declare all the needed things to work with IPsec. o All IPsec protocols handlers (ESP/AH/IPCOMP protosw) were removed. Now these protocols are handled directly via IPsec methods. o TCP_SIGNATURE support was reworked to be more close to RFC. o PF_KEY SADB was reworked: - now all security associations stored in the single SPI namespace, and all SAs MUST have unique SPI. - several hash tables added to speed up lookups in SADB. - SADB now uses rmlock to protect access, and concurrent threads can do SA lookups in the same time. - many PF_KEY message handlers were reworked to reflect changes in SADB. - SADB_UPDATE message was extended to support new PF_KEY headers: SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST. They can be used by IKE daemon to change SA addresses. o ipsecrequest and secpolicy structures were cardinally changed to avoid locking protection for ipsecrequest. Now we support only limited number (4) of bundled SAs, but they are supported for both INET and INET6. o INPCB security policy cache was introduced. Each PCB now caches used security policies to avoid SP lookup for each packet. o For inbound security policies added the mode, when the kernel does check for full history of applied IPsec transforms. o References counting rules for security policies and security associations were changed. The proper SA locking added into xform code. o xform code was also changed. Now it is possible to unregister xforms. tdb_xxx structures were changed and renamed to reflect changes in SADB/SPDB, and changed rules for locking and refcounting. Reviewed by: gnn, wblock Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D9352
2017-02-06 08:49:57 +00:00
# Option IPSEC_SUPPORT does not enable IPsec, but makes it possible to
# load it as a kernel module. You still MUST add device crypto to your kernel
# configuration.
options IPSEC_SUPPORT
#options IPSEC_DEBUG #debug for IP security
Add kernel-side support for in-kernel TLS. KTLS adds support for in-kernel framing and encryption of Transport Layer Security (1.0-1.2) data on TCP sockets. KTLS only supports offload of TLS for transmitted data. Key negotation must still be performed in userland. Once completed, transmit session keys for a connection are provided to the kernel via a new TCP_TXTLS_ENABLE socket option. All subsequent data transmitted on the socket is placed into TLS frames and encrypted using the supplied keys. Any data written to a KTLS-enabled socket via write(2), aio_write(2), or sendfile(2) is assumed to be application data and is encoded in TLS frames with an application data type. Individual records can be sent with a custom type (e.g. handshake messages) via sendmsg(2) with a new control message (TLS_SET_RECORD_TYPE) specifying the record type. At present, rekeying is not supported though the in-kernel framework should support rekeying. KTLS makes use of the recently added unmapped mbufs to store TLS frames in the socket buffer. Each TLS frame is described by a single ext_pgs mbuf. The ext_pgs structure contains the header of the TLS record (and trailer for encrypted records) as well as references to the associated TLS session. KTLS supports two primary methods of encrypting TLS frames: software TLS and ifnet TLS. Software TLS marks mbufs holding socket data as not ready via M_NOTREADY similar to sendfile(2) when TLS framing information is added to an unmapped mbuf in ktls_frame(). ktls_enqueue() is then called to schedule TLS frames for encryption. In the case of sendfile_iodone() calls ktls_enqueue() instead of pru_ready() leaving the mbufs marked M_NOTREADY until encryption is completed. For other writes (vn_sendfile when pages are available, write(2), etc.), the PRUS_NOTREADY is set when invoking pru_send() along with invoking ktls_enqueue(). A pool of worker threads (the "KTLS" kernel process) encrypts TLS frames queued via ktls_enqueue(). Each TLS frame is temporarily mapped using the direct map and passed to a software encryption backend to perform the actual encryption. (Note: The use of PHYS_TO_DMAP could be replaced with sf_bufs if someone wished to make this work on architectures without a direct map.) KTLS supports pluggable software encryption backends. Internally, Netflix uses proprietary pure-software backends. This commit includes a simple backend in a new ktls_ocf.ko module that uses the kernel's OpenCrypto framework to provide AES-GCM encryption of TLS frames. As a result, software TLS is now a bit of a misnomer as it can make use of hardware crypto accelerators. Once software encryption has finished, the TLS frame mbufs are marked ready via pru_ready(). At this point, the encrypted data appears as regular payload to the TCP stack stored in unmapped mbufs. ifnet TLS permits a NIC to offload the TLS encryption and TCP segmentation. In this mode, a new send tag type (IF_SND_TAG_TYPE_TLS) is allocated on the interface a socket is routed over and associated with a TLS session. TLS records for a TLS session using ifnet TLS are not marked M_NOTREADY but are passed down the stack unencrypted. The ip_output_send() and ip6_output_send() helper functions that apply send tags to outbound IP packets verify that the send tag of the TLS record matches the outbound interface. If so, the packet is tagged with the TLS send tag and sent to the interface. The NIC device driver must recognize packets with the TLS send tag and schedule them for TLS encryption and TCP segmentation. If the the outbound interface does not match the interface in the TLS send tag, the packet is dropped. In addition, a task is scheduled to refresh the TLS send tag for the TLS session. If a new TLS send tag cannot be allocated, the connection is dropped. If a new TLS send tag is allocated, however, subsequent packets will be tagged with the correct TLS send tag. (This latter case has been tested by configuring both ports of a Chelsio T6 in a lagg and failing over from one port to another. As the connections migrated to the new port, new TLS send tags were allocated for the new port and connections resumed without being dropped.) ifnet TLS can be enabled and disabled on supported network interfaces via new '[-]txtls[46]' options to ifconfig(8). ifnet TLS is supported across both vlan devices and lagg interfaces using failover, lacp with flowid enabled, or lacp with flowid enabled. Applications may request the current KTLS mode of a connection via a new TCP_TXTLS_MODE socket option. They can also use this socket option to toggle between software and ifnet TLS modes. In addition, a testing tool is available in tools/tools/switch_tls. This is modeled on tcpdrop and uses similar syntax. However, instead of dropping connections, -s is used to force KTLS connections to switch to software TLS and -i is used to switch to ifnet TLS. Various sysctls and counters are available under the kern.ipc.tls sysctl node. The kern.ipc.tls.enable node must be set to true to enable KTLS (it is off by default). The use of unmapped mbufs must also be enabled via kern.ipc.mb_use_ext_pgs to enable KTLS. KTLS is enabled via the KERN_TLS kernel option. This patch is the culmination of years of work by several folks including Scott Long and Randall Stewart for the original design and implementation; Drew Gallatin for several optimizations including the use of ext_pgs mbufs, the M_NOTREADY mechanism for TLS records awaiting software encryption, and pluggable software crypto backends; and John Baldwin for modifications to support hardware TLS offload. Reviewed by: gallatin, hselasky, rrs Obtained from: Netflix Sponsored by: Netflix, Chelsio Communications Differential Revision: https://reviews.freebsd.org/D21277
2019-08-27 00:01:56 +00:00
# TLS framing and encryption/decryption of data over TCP sockets.
options KERN_TLS # TLS transmit and receive offload
Add kernel-side support for in-kernel TLS. KTLS adds support for in-kernel framing and encryption of Transport Layer Security (1.0-1.2) data on TCP sockets. KTLS only supports offload of TLS for transmitted data. Key negotation must still be performed in userland. Once completed, transmit session keys for a connection are provided to the kernel via a new TCP_TXTLS_ENABLE socket option. All subsequent data transmitted on the socket is placed into TLS frames and encrypted using the supplied keys. Any data written to a KTLS-enabled socket via write(2), aio_write(2), or sendfile(2) is assumed to be application data and is encoded in TLS frames with an application data type. Individual records can be sent with a custom type (e.g. handshake messages) via sendmsg(2) with a new control message (TLS_SET_RECORD_TYPE) specifying the record type. At present, rekeying is not supported though the in-kernel framework should support rekeying. KTLS makes use of the recently added unmapped mbufs to store TLS frames in the socket buffer. Each TLS frame is described by a single ext_pgs mbuf. The ext_pgs structure contains the header of the TLS record (and trailer for encrypted records) as well as references to the associated TLS session. KTLS supports two primary methods of encrypting TLS frames: software TLS and ifnet TLS. Software TLS marks mbufs holding socket data as not ready via M_NOTREADY similar to sendfile(2) when TLS framing information is added to an unmapped mbuf in ktls_frame(). ktls_enqueue() is then called to schedule TLS frames for encryption. In the case of sendfile_iodone() calls ktls_enqueue() instead of pru_ready() leaving the mbufs marked M_NOTREADY until encryption is completed. For other writes (vn_sendfile when pages are available, write(2), etc.), the PRUS_NOTREADY is set when invoking pru_send() along with invoking ktls_enqueue(). A pool of worker threads (the "KTLS" kernel process) encrypts TLS frames queued via ktls_enqueue(). Each TLS frame is temporarily mapped using the direct map and passed to a software encryption backend to perform the actual encryption. (Note: The use of PHYS_TO_DMAP could be replaced with sf_bufs if someone wished to make this work on architectures without a direct map.) KTLS supports pluggable software encryption backends. Internally, Netflix uses proprietary pure-software backends. This commit includes a simple backend in a new ktls_ocf.ko module that uses the kernel's OpenCrypto framework to provide AES-GCM encryption of TLS frames. As a result, software TLS is now a bit of a misnomer as it can make use of hardware crypto accelerators. Once software encryption has finished, the TLS frame mbufs are marked ready via pru_ready(). At this point, the encrypted data appears as regular payload to the TCP stack stored in unmapped mbufs. ifnet TLS permits a NIC to offload the TLS encryption and TCP segmentation. In this mode, a new send tag type (IF_SND_TAG_TYPE_TLS) is allocated on the interface a socket is routed over and associated with a TLS session. TLS records for a TLS session using ifnet TLS are not marked M_NOTREADY but are passed down the stack unencrypted. The ip_output_send() and ip6_output_send() helper functions that apply send tags to outbound IP packets verify that the send tag of the TLS record matches the outbound interface. If so, the packet is tagged with the TLS send tag and sent to the interface. The NIC device driver must recognize packets with the TLS send tag and schedule them for TLS encryption and TCP segmentation. If the the outbound interface does not match the interface in the TLS send tag, the packet is dropped. In addition, a task is scheduled to refresh the TLS send tag for the TLS session. If a new TLS send tag cannot be allocated, the connection is dropped. If a new TLS send tag is allocated, however, subsequent packets will be tagged with the correct TLS send tag. (This latter case has been tested by configuring both ports of a Chelsio T6 in a lagg and failing over from one port to another. As the connections migrated to the new port, new TLS send tags were allocated for the new port and connections resumed without being dropped.) ifnet TLS can be enabled and disabled on supported network interfaces via new '[-]txtls[46]' options to ifconfig(8). ifnet TLS is supported across both vlan devices and lagg interfaces using failover, lacp with flowid enabled, or lacp with flowid enabled. Applications may request the current KTLS mode of a connection via a new TCP_TXTLS_MODE socket option. They can also use this socket option to toggle between software and ifnet TLS modes. In addition, a testing tool is available in tools/tools/switch_tls. This is modeled on tcpdrop and uses similar syntax. However, instead of dropping connections, -s is used to force KTLS connections to switch to software TLS and -i is used to switch to ifnet TLS. Various sysctls and counters are available under the kern.ipc.tls sysctl node. The kern.ipc.tls.enable node must be set to true to enable KTLS (it is off by default). The use of unmapped mbufs must also be enabled via kern.ipc.mb_use_ext_pgs to enable KTLS. KTLS is enabled via the KERN_TLS kernel option. This patch is the culmination of years of work by several folks including Scott Long and Randall Stewart for the original design and implementation; Drew Gallatin for several optimizations including the use of ext_pgs mbufs, the M_NOTREADY mechanism for TLS records awaiting software encryption, and pluggable software crypto backends; and John Baldwin for modifications to support hardware TLS offload. Reviewed by: gallatin, hselasky, rrs Obtained from: Netflix Sponsored by: Netflix, Chelsio Communications Differential Revision: https://reviews.freebsd.org/D21277
2019-08-27 00:01:56 +00:00
# Netlink kernel/user<>kernel/user messaging interface
options NETLINK
#
# SMB/CIFS requester
# NETSMB enables support for SMB protocol, it requires LIBMCHAIN and LIBICONV
# options.
options NETSMB #SMB/CIFS requester
# mchain library. It can be either loaded as KLD or compiled into kernel
options LIBMCHAIN
2005-05-06 14:47:54 +00:00
# libalias library, performing NAT
options LIBALIAS
2005-05-06 14:47:54 +00:00
#
# SCTP is a NEW transport protocol defined by
# RFC2960 updated by RFC3309 and RFC3758.. and
# soon to have a new base RFC and many many more
# extensions. This release supports all the extensions
# including many drafts (most about to become RFC's).
# It is the reference implementation of SCTP
# and is quite well tested.
#
# Note YOU MUST have both INET and INET6 defined.
# You don't have to enable V6, but SCTP is
# dual stacked and so far we have not torn apart
# the V6 and V4.. since an association can span
# both a V6 and V4 address at the SAME time :-)
#
# The SCTP_SUPPORT option does not enable SCTP, but provides the necessary
# support for loading SCTP as a loadable kernel module.
#
options SCTP
options SCTP_SUPPORT
# There are bunches of options:
# this one turns on all sorts of
# nastily printing that you can
# do. It's all controlled by a
# bit mask (settable by socket opt and
# by sysctl). Including will not cause
# logging until you set the bits.. but it
# can be quite verbose.. so without this
# option we don't do any of the tests for
# bits and prints.. which makes the code run
# faster.. if you are not debugging don't use.
options SCTP_DEBUG
#
# All that options after that turn on specific types of
# logging. You can monitor CWND growth, flight size
# and all sorts of things. Go look at the code and
# see. I have used this to produce interesting
# charts and graphs as well :->
#
# I have not yet committed the tools to get and print
# the logs, I will do that eventually .. before then
# if you want them send me an email rrs@freebsd.org
2009-10-29 09:51:13 +00:00
# You basically must have ktr(4) enabled for these
# and you then set the sysctl to turn on/off various
2009-10-29 09:51:13 +00:00
# logging bits. Use ktrdump(8) to pull the log and run
# it through a display program.. and graphs and other
# things too.
#
options SCTP_LOCK_LOGGING
options SCTP_MBUF_LOGGING
options SCTP_MBCNT_LOGGING
options SCTP_PACKET_LOGGING
options SCTP_LTRACE_CHUNKS
options SCTP_LTRACE_ERRORS
# altq(9). Enable the base part of the hooks with the ALTQ option.
# Individual disciplines must be built into the base system and can not be
# loaded as modules at this point. ALTQ requires a stable TSC so if yours is
# broken or changes with CPU throttling then you must also have the ALTQ_NOPCC
# option.
options ALTQ
2007-11-06 02:42:00 +00:00
options ALTQ_CBQ # Class Based Queueing
options ALTQ_RED # Random Early Detection
options ALTQ_RIO # RED In/Out
options ALTQ_CODEL # CoDel Active Queueing
options ALTQ_HFSC # Hierarchical Packet Scheduler
options ALTQ_FAIRQ # Fair Packet Scheduler
options ALTQ_CDNR # Traffic conditioner
2004-06-26 17:19:44 +00:00
options ALTQ_PRIQ # Priority Queueing
options ALTQ_NOPCC # Required if the TSC is unusable
options ALTQ_DEBUG
# netgraph(4). Enable the base netgraph code with the NETGRAPH option.
# Individual node types can be enabled with the corresponding option
# listed below; however, this is not strictly necessary as netgraph
# will automatically load the corresponding KLD module if the node type
# is not already compiled into the kernel. Each type below has a
# corresponding man page, e.g., ng_async(8).
options NETGRAPH # netgraph(4) system
options NETGRAPH_DEBUG # enable extra debugging, this
# affects netgraph(4) and nodes
# Node types
options NETGRAPH_ASYNC
options NETGRAPH_BLUETOOTH # ng_bluetooth(4)
options NETGRAPH_BLUETOOTH_HCI # ng_hci(4)
options NETGRAPH_BLUETOOTH_L2CAP # ng_l2cap(4)
options NETGRAPH_BLUETOOTH_SOCKET # ng_btsocket(4)
options NETGRAPH_BLUETOOTH_UBT # ng_ubt(4)
options NETGRAPH_BLUETOOTH_UBTBCMFW # ubtbcmfw(4)
options NETGRAPH_BPF
options NETGRAPH_BRIDGE
options NETGRAPH_CAR
options NETGRAPH_CHECKSUM
options NETGRAPH_CISCO
options NETGRAPH_DEFLATE
options NETGRAPH_DEVICE
options NETGRAPH_ECHO
options NETGRAPH_EIFACE
options NETGRAPH_ETHER
options NETGRAPH_FRAME_RELAY
options NETGRAPH_GIF
options NETGRAPH_GIF_DEMUX
options NETGRAPH_HOLE
options NETGRAPH_IFACE
options NETGRAPH_IP_INPUT
options NETGRAPH_IPFW
1999-11-16 23:30:05 +00:00
options NETGRAPH_KSOCKET
options NETGRAPH_L2TP
options NETGRAPH_LMI
options NETGRAPH_MPPC_COMPRESSION
options NETGRAPH_MPPC_ENCRYPTION
options NETGRAPH_NETFLOW
options NETGRAPH_NAT
2000-11-16 16:59:26 +00:00
options NETGRAPH_ONE2MANY
options NETGRAPH_PATCH
options NETGRAPH_PIPE
options NETGRAPH_PPP
options NETGRAPH_PPPOE
options NETGRAPH_PPTPGRE
options NETGRAPH_PRED1
options NETGRAPH_RFC1490
options NETGRAPH_SOCKET
options NETGRAPH_SPLIT
options NETGRAPH_TAG
2005-06-10 08:05:13 +00:00
options NETGRAPH_TCPMSS
options NETGRAPH_TEE
options NETGRAPH_UI
options NETGRAPH_VJC
options NETGRAPH_VLAN
2013-04-02 05:57:36 +00:00
# Network stack virtualization.
options VIMAGE
options VNET_DEBUG # debug for VIMAGE
2013-04-02 05:57:36 +00:00
#
# Network interfaces:
Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others
2000-06-13 22:28:50 +00:00
# The `loop' device is MANDATORY when networking is enabled.
device loop
Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others
2000-06-13 22:28:50 +00:00
# The `ether' device provides generic code to handle
# Ethernets; it is MANDATORY when an Ethernet device driver is
# configured.
device ether
# The `vlan' device implements the VLAN tagging of Ethernet frames
# according to IEEE 802.1Q.
device vlan
# The `vxlan' device implements the VXLAN encapsulation of Ethernet
# frames in UDP packets according to RFC7348.
device vxlan
2003-07-07 21:12:34 +00:00
# The `wlan' device provides generic code to support 802.11
# drivers, including host AP mode; it is MANDATORY for the wi,
# and ath drivers and will eventually be required by all 802.11 drivers.
device wlan
options IEEE80211_DEBUG #enable debugging msgs
Implementation of the upcoming Wireless Mesh standard, 802.11s, on the net80211 wireless stack. This work is based on the March 2009 D3.0 draft standard. This standard is expected to become final next year. This includes two main net80211 modules, ieee80211_mesh.c which deals with peer link management, link metric calculation, routing table control and mesh configuration and ieee80211_hwmp.c which deals with the actually routing process on the mesh network. HWMP is the mandatory routing protocol on by the mesh standard, but others, such as RA-OLSR, can be implemented. Authentication and encryption are not implemented. There are several scripts under tools/tools/net80211/scripts that can be used to test different mesh network topologies and they also teach you how to setup a mesh vap (for the impatient: ifconfig wlan0 create wlandev ... wlanmode mesh). A new build option is available: IEEE80211_SUPPORT_MESH and it's enabled by default on GENERIC kernels for i386, amd64, sparc64 and pc98. Drivers that support mesh networks right now are: ath, ral and mwl. More information at: http://wiki.freebsd.org/WifiMesh Please note that this work is experimental. Also, please note that bridging a mesh vap with another network interface is not yet supported. Many thanks to the FreeBSD Foundation for sponsoring this project and to Sam Leffler for his support. Also, I would like to thank Gateworks Corporation for sending me a Cambria board which was used during the development of this project. Reviewed by: sam Approved by: re (kensmith) Obtained from: projects/mesh11s
2009-07-11 15:02:45 +00:00
options IEEE80211_SUPPORT_MESH #enable 802.11s D3.0 support
options IEEE80211_SUPPORT_TDMA #enable TDMA support
# The `wlan_wep', `wlan_tkip', and `wlan_ccmp' devices provide
# support for WEP, TKIP, and AES-CCMP crypto protocols optionally
# used with 802.11 devices that depend on the `wlan' module.
device wlan_wep
device wlan_ccmp
device wlan_tkip
# The `wlan_xauth' device provides support for external (i.e. user-mode)
# authenticators for use with 802.11 drivers that use the `wlan'
2005-01-05 22:33:11 +00:00
# module and support 802.1x and/or WPA security protocols.
device wlan_xauth
# The `wlan_acl' device provides a MAC-based access control mechanism
# for use with 802.11 drivers operating in ap mode and using the
# `wlan' module.
# The 'wlan_amrr' device provides AMRR transmit rate control algorithm
device wlan_acl
device wlan_amrr
Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others
2000-06-13 22:28:50 +00:00
# The `bpf' device enables the Berkeley Packet Filter. Be
# aware of the legal and administrative consequences of enabling this
# option. DHCP requires bpf.
device bpf
# The `netmap' device implements memory-mapped access to network
# devices from userspace, enabling wire-speed packet capture and
# generation even at 10Gbit/s. Requires support in the device
# driver. Supported drivers are ixgbe, e1000, re.
device netmap
Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others
2000-06-13 22:28:50 +00:00
# The `disc' device implements a minimal network interface,
# which throws away all packets sent and never receives any. It is
# included for testing and benchmarking purposes.
device disc
# The `epair' device implements a virtual back-to-back connected Ethernet
# like interface pair.
device epair
# The `edsc' device implements a minimal Ethernet interface,
# which discards all packets sent and receives none.
device edsc
tun/tap: merge and rename to `tuntap` tun(4) and tap(4) share the same general management interface and have a lot in common. Bugs exist in tap(4) that have been fixed in tun(4), and vice-versa. Let's reduce the maintenance requirements by merging them together and using flags to differentiate between the three interface types (tun, tap, vmnet). This fixes a couple of tap(4)/vmnet(4) issues right out of the gate: - tap devices may no longer be destroyed while they're open [0] - VIMAGE issues already addressed in tun by kp [0] emaste had removed an easy-panic-button in r240938 due to devdrn blocking. A naive glance over this leads me to believe that this isn't quite complete -- destroy_devl will only block while executing d_* functions, but doesn't block the device from being destroyed while a process has it open. The latter is the intent of the condvar in tun, so this is "fixed" (for certain definitions of the word -- it wasn't really broken in tap, it just wasn't quite ideal). ifconfig(8) also grew the ability to map an interface name to a kld, so that `ifconfig {tun,tap}0` can continue to autoload the correct module, and `ifconfig vmnet0 create` will now autoload the correct module. This is a low overhead addition. (MFC commentary) This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this, and how critical they are. Changes after this are likely easily MFC'd without taking this merge, but the merge will be easier. I have no plans to do this MFC as of now. Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill) Input also from: melifaro Relnotes: yes Differential Revision: https://reviews.freebsd.org/D20044
2019-05-08 02:32:11 +00:00
# The `tuntap' device implements (user-)ppp, nos-tun(8) and a pty-like virtual
# Ethernet interface
device tuntap
Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others
2000-06-13 22:28:50 +00:00
# The `gif' device implements IPv6 over IP4 tunneling,
# IPv4 over IPv6 tunneling, IPv4 over IPv4 tunneling and
# IPv6 over IPv6 tunneling.
# The `gre' device implements GRE (Generic Routing Encapsulation) tunneling,
# as specified in the RFC 2784 and RFC 2890.
# The `me' device implements Minimal Encapsulation within IPv4 as
# specified in the RFC 2004.
2000-11-08 10:09:01 +00:00
# The XBONEHACK option allows the same pair of addresses to be configured on
# multiple gif interfaces.
device gif
device gre
device me
options XBONEHACK
# The `stf' device implements 6to4 encapsulation.
device stf
# The pf packet filter consists of three devices:
# The `pf' device provides /dev/pf and the firewall code itself.
# The `pflog' device provides the pflog0 interface which logs packets.
# The `pfsync' device provides the pfsync0 interface used for
# synchronization of firewall state tables (over the net).
device pf
device pflog
device pfsync
# Bridge interface.
device if_bridge
# Common Address Redundancy Protocol. See carp(4) for more details.
device carp
# IPsec interface.
device enc
# Link aggregation interface.
device lagg
# WireGuard interface.
device wg
#
# Internet family options:
#
# MROUTING enables the kernel multicast packet forwarder, which works
# with mrouted and XORP.
#
# IPFIREWALL enables support for IP firewall construction, in
# conjunction with the `ipfw' program. IPFIREWALL_VERBOSE sends
# logged packets to the system logger. IPFIREWALL_VERBOSE_LIMIT
# limits the number of times a matching entry can be logged.
#
# WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any"
# and if you do not add other rules during startup to allow access,
1999-09-23 04:22:33 +00:00
# YOU WILL LOCK YOURSELF OUT. It is suggested that you set firewall_type=open
# in /etc/rc.conf when first enabling this feature, then refining the
# firewall rules in /etc/rc.firewall after you've tested that the new kernel
# feature works properly.
1997-09-23 16:28:00 +00:00
#
# IPFIREWALL_DEFAULT_TO_ACCEPT causes the default rule (at boot) to
# allow everything. Use with care, if a cracker can crash your
# firewall machine, they can get to your protected machines. However,
# if you are using it as an as-needed filter for specific problems as
# they arise, then this may be for you. Changing the default to 'allow'
# means that you won't get stuck if the kernel and /sbin/ipfw binary get
# out of sync.
#
# IPDIVERT enables the divert IP sockets, used by ``ipfw divert''. It
# depends on IPFIREWALL if compiled into the kernel.
#
# IPFIREWALL_NAT adds support for in kernel nat in ipfw, and it requires
# LIBALIAS.
#
Add ipfw_nat64 module that implements stateless and stateful NAT64. The module works together with ipfw(4) and implemented as its external action module. Stateless NAT64 registers external action with name nat64stl. This keyword should be used to create NAT64 instance and to address this instance in rules. Stateless NAT64 uses two lookup tables with mapped IPv4->IPv6 and IPv6->IPv4 addresses to perform translation. A configuration of instance should looks like this: 1. Create lookup tables: # ipfw table T46 create type addr valtype ipv6 # ipfw table T64 create type addr valtype ipv4 2. Fill T46 and T64 tables. 3. Add rule to allow neighbor solicitation and advertisement: # ipfw add allow icmp6 from any to any icmp6types 135,136 4. Create NAT64 instance: # ipfw nat64stl NAT create table4 T46 table6 T64 5. Add rules that matches the traffic: # ipfw add nat64stl NAT ip from any to table(T46) # ipfw add nat64stl NAT ip from table(T64) to 64:ff9b::/96 6. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96 via NAT64 host. Stateful NAT64 registers external action with name nat64lsn. The only one option required to create nat64lsn instance - prefix4. It defines the pool of IPv4 addresses used for translation. A configuration of instance should looks like this: 1. Add rule to allow neighbor solicitation and advertisement: # ipfw add allow icmp6 from any to any icmp6types 135,136 2. Create NAT64 instance: # ipfw nat64lsn NAT create prefix4 A.B.C.D/28 3. Add rules that matches the traffic: # ipfw add nat64lsn NAT ip from any to A.B.C.D/28 # ipfw add nat64lsn NAT ip6 from any to 64:ff9b::/96 4. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96 via NAT64 host. Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D6434
2016-08-13 16:09:49 +00:00
# IPFIREWALL_NAT64 adds support for in kernel NAT64 in ipfw.
#
# IPFIREWALL_NPTV6 adds support for in kernel NPTv6 in ipfw.
#
# IPFIREWALL_PMOD adds support for protocols modification module. Currently
# it supports only TCP MSS modification.
#
# IPSTEALTH enables code to support stealth forwarding (i.e., forwarding
2006-08-24 08:00:02 +00:00
# packets without touching the TTL). This can be useful to hide firewalls
# from traceroute and similar tools.
#
# PF_DEFAULT_TO_DROP causes the default pf(4) rule to deny everything.
#
There are times when it would be really nice to have a record of the last few packets and/or state transitions from each TCP socket. That would help with narrowing down certain problems we see in the field that are hard to reproduce without understanding the history of how we got into a certain state. This change provides just that. It saves copies of the last N packets in a list in the tcpcb. When the tcpcb is destroyed, the list is freed. I thought this was likely to be more performance-friendly than saving copies of the tcpcb. Plus, with the packets, you should be able to reverse-engineer what happened to the tcpcb. To enable the feature, you will need to compile a kernel with the TCPPCAP option. Even then, the feature defaults to being deactivated. You can activate it by setting a positive value for the number of captured packets. You can do that on either a global basis or on a per-socket basis (via a setsockopt call). There is no way to get the packets out of the kernel other than using kmem or getting a coredump. I thought that would help some of the legal/privacy concerns regarding such a feature. However, it should be possible to add a future effort to export them in PCAP format. I tested this at low scale, and found that there were no mbuf leaks and the peak mbuf usage appeared to be unchanged with and without the feature. The main performance concern I can envision is the number of mbufs that would be used on systems with a large number of sockets. If you save five packets per direction per socket and have 3,000 sockets, that will consume at least 30,000 mbufs just to keep these packets. I tried to reduce the concerns associated with this by limiting the number of clusters (not mbufs) that could be used for this feature. Again, in my testing, that appears to work correctly. Differential Revision: D3100 Submitted by: Jonathan Looney <jlooney at juniper dot net> Reviewed by: gnn, hiren
2015-10-14 00:35:37 +00:00
# TCPPCAP enables code which keeps the last n packets sent and received
# on a TCP socket.
#
# TCP_BLACKBOX enables enhanced TCP event logging.
#
# TCP_HHOOK enables the hhook(9) framework hooks for the TCP stack.
#
Introduce scalable route multipath. This change is based on the nexthop objects landed in D24232. The change introduces the concept of nexthop groups. Each group contains the collection of nexthops with their relative weights and a dataplane-optimized structure to enable efficient nexthop selection. Simular to the nexthops, nexthop groups are immutable. Dataplane part gets compiled during group creation and is basically an array of nexthop pointers, compiled w.r.t their weights. With this change, `rt_nhop` field of `struct rtentry` contains either nexthop or nexthop group. They are distinguished by the presense of NHF_MULTIPATH flag. All dataplane lookup functions returns pointer to the nexthop object, leaving nexhop groups details inside routing subsystem. User-visible changes: The change is intended to be backward-compatible: all non-mpath operations should work as before with ROUTE_MPATH and net.route.multipath=1. All routes now comes with weight, default weight is 1, maximum is 2^24-1. Current maximum multipath group width is statically set to 64. This will become sysctl-tunable in the followup changes. Using functionality: * Recompile kernel with ROUTE_MPATH * set net.route.multipath to 1 route add -6 2001:db8::/32 2001:db8::2 -weight 10 route add -6 2001:db8::/32 2001:db8::3 -weight 20 netstat -6On Nexthop groups data Internet6: GrpIdx NhIdx Weight Slots Gateway Netif Refcnt 1 ------- ------- ------- --------------------------------------- --------- 1 13 10 1 2001:db8::2 vlan2 14 20 2 2001:db8::3 vlan2 Next steps: * Land outbound hashing for locally-originated routes ( D26523 ). * Fix net/bird multipath (net/frr seems to work fine) * Add ROUTE_MPATH to GENERIC * Set net.route.multipath=1 by default Tested by: olivier Reviewed by: glebius Relnotes: yes Differential Revision: https://reviews.freebsd.org/D26449
2020-10-03 10:47:17 +00:00
# ROUTE_MPATH provides support for multipath routing.
2011-12-15 11:15:23 +00:00
#
options MROUTING # Multicast routing
options IPFIREWALL #firewall
options IPFIREWALL_VERBOSE #enable logging to syslogd(8)
options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity
options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default
options IPFIREWALL_NAT #ipfw kernel nat support
Add ipfw_nat64 module that implements stateless and stateful NAT64. The module works together with ipfw(4) and implemented as its external action module. Stateless NAT64 registers external action with name nat64stl. This keyword should be used to create NAT64 instance and to address this instance in rules. Stateless NAT64 uses two lookup tables with mapped IPv4->IPv6 and IPv6->IPv4 addresses to perform translation. A configuration of instance should looks like this: 1. Create lookup tables: # ipfw table T46 create type addr valtype ipv6 # ipfw table T64 create type addr valtype ipv4 2. Fill T46 and T64 tables. 3. Add rule to allow neighbor solicitation and advertisement: # ipfw add allow icmp6 from any to any icmp6types 135,136 4. Create NAT64 instance: # ipfw nat64stl NAT create table4 T46 table6 T64 5. Add rules that matches the traffic: # ipfw add nat64stl NAT ip from any to table(T46) # ipfw add nat64stl NAT ip from table(T64) to 64:ff9b::/96 6. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96 via NAT64 host. Stateful NAT64 registers external action with name nat64lsn. The only one option required to create nat64lsn instance - prefix4. It defines the pool of IPv4 addresses used for translation. A configuration of instance should looks like this: 1. Add rule to allow neighbor solicitation and advertisement: # ipfw add allow icmp6 from any to any icmp6types 135,136 2. Create NAT64 instance: # ipfw nat64lsn NAT create prefix4 A.B.C.D/28 3. Add rules that matches the traffic: # ipfw add nat64lsn NAT ip from any to A.B.C.D/28 # ipfw add nat64lsn NAT ip6 from any to 64:ff9b::/96 4. Configure DNS64 for IPv6 clients and add route to 64:ff9b::/96 via NAT64 host. Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D6434
2016-08-13 16:09:49 +00:00
options IPFIREWALL_NAT64 #ipfw kernel NAT64 support
options IPFIREWALL_NPTV6 #ipfw kernel IPv6 NPT support
options IPDIVERT #divert sockets
options IPFILTER #ipfilter support
options IPFILTER_LOG #ipfilter logging
options IPFILTER_LOOKUP #ipfilter pools
options IPFILTER_DEFAULT_BLOCK #block all packets by default
options IPSTEALTH #support for stealth forwarding
options PF_DEFAULT_TO_DROP #drop everything by default
There are times when it would be really nice to have a record of the last few packets and/or state transitions from each TCP socket. That would help with narrowing down certain problems we see in the field that are hard to reproduce without understanding the history of how we got into a certain state. This change provides just that. It saves copies of the last N packets in a list in the tcpcb. When the tcpcb is destroyed, the list is freed. I thought this was likely to be more performance-friendly than saving copies of the tcpcb. Plus, with the packets, you should be able to reverse-engineer what happened to the tcpcb. To enable the feature, you will need to compile a kernel with the TCPPCAP option. Even then, the feature defaults to being deactivated. You can activate it by setting a positive value for the number of captured packets. You can do that on either a global basis or on a per-socket basis (via a setsockopt call). There is no way to get the packets out of the kernel other than using kmem or getting a coredump. I thought that would help some of the legal/privacy concerns regarding such a feature. However, it should be possible to add a future effort to export them in PCAP format. I tested this at low scale, and found that there were no mbuf leaks and the peak mbuf usage appeared to be unchanged with and without the feature. The main performance concern I can envision is the number of mbufs that would be used on systems with a large number of sockets. If you save five packets per direction per socket and have 3,000 sockets, that will consume at least 30,000 mbufs just to keep these packets. I tried to reduce the concerns associated with this by limiting the number of clusters (not mbufs) that could be used for this feature. Again, in my testing, that appears to work correctly. Differential Revision: D3100 Submitted by: Jonathan Looney <jlooney at juniper dot net> Reviewed by: gnn, hiren
2015-10-14 00:35:37 +00:00
options TCPPCAP
options TCP_BLACKBOX
options TCP_HHOOK
Introduce scalable route multipath. This change is based on the nexthop objects landed in D24232. The change introduces the concept of nexthop groups. Each group contains the collection of nexthops with their relative weights and a dataplane-optimized structure to enable efficient nexthop selection. Simular to the nexthops, nexthop groups are immutable. Dataplane part gets compiled during group creation and is basically an array of nexthop pointers, compiled w.r.t their weights. With this change, `rt_nhop` field of `struct rtentry` contains either nexthop or nexthop group. They are distinguished by the presense of NHF_MULTIPATH flag. All dataplane lookup functions returns pointer to the nexthop object, leaving nexhop groups details inside routing subsystem. User-visible changes: The change is intended to be backward-compatible: all non-mpath operations should work as before with ROUTE_MPATH and net.route.multipath=1. All routes now comes with weight, default weight is 1, maximum is 2^24-1. Current maximum multipath group width is statically set to 64. This will become sysctl-tunable in the followup changes. Using functionality: * Recompile kernel with ROUTE_MPATH * set net.route.multipath to 1 route add -6 2001:db8::/32 2001:db8::2 -weight 10 route add -6 2001:db8::/32 2001:db8::3 -weight 20 netstat -6On Nexthop groups data Internet6: GrpIdx NhIdx Weight Slots Gateway Netif Refcnt 1 ------- ------- ------- --------------------------------------- --------- 1 13 10 1 2001:db8::2 vlan2 14 20 2 2001:db8::3 vlan2 Next steps: * Land outbound hashing for locally-originated routes ( D26523 ). * Fix net/bird multipath (net/frr seems to work fine) * Add ROUTE_MPATH to GENERIC * Set net.route.multipath=1 by default Tested by: olivier Reviewed by: glebius Relnotes: yes Differential Revision: https://reviews.freebsd.org/D26449
2020-10-03 10:47:17 +00:00
options ROUTE_MPATH
# The MBUF_STRESS_TEST option enables options which create
# various random failures / extreme cases related to mbuf
# functions. See mbuf(9) for a list of available test cases.
2008-05-06 22:41:23 +00:00
# MBUF_PROFILING enables code to profile the mbuf chains
# exiting the system (via participating interfaces) and
# return a logarithmic histogram of monitored parameters
# (e.g. packet size, wasted space, number of mbufs in chain).
options MBUF_STRESS_TEST
options MBUF_PROFILING
# Statically link in accept filters
options ACCEPT_FILTER_DATA
options ACCEPT_FILTER_DNS
options ACCEPT_FILTER_HTTP
# TCP_SIGNATURE adds support for RFC 2385 (TCP-MD5) digests. These are
# carried in TCP option 19. This option is commonly used to protect
# TCP sessions (e.g. BGP) where IPSEC is not available nor desirable.
# This is enabled on a per-socket basis using the TCP_MD5SIG socket option.
Merge projects/ipsec into head/. Small summary ------------- o Almost all IPsec releated code was moved into sys/netipsec. o New kernel modules added: ipsec.ko and tcpmd5.ko. New kernel option IPSEC_SUPPORT added. It enables support for loading and unloading of ipsec.ko and tcpmd5.ko kernel modules. o IPSEC_NAT_T option was removed. Now NAT-T support is enabled by default. The UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type support was removed. Added TCP/UDP checksum handling for inbound packets that were decapsulated by transport mode SAs. setkey(8) modified to show run-time NAT-T configuration of SA. o New network pseudo interface if_ipsec(4) added. For now it is build as part of ipsec.ko module (or with IPSEC kernel). It implements IPsec virtual tunnels to create route-based VPNs. o The network stack now invokes IPsec functions using special methods. The only one header file <netipsec/ipsec_support.h> should be included to declare all the needed things to work with IPsec. o All IPsec protocols handlers (ESP/AH/IPCOMP protosw) were removed. Now these protocols are handled directly via IPsec methods. o TCP_SIGNATURE support was reworked to be more close to RFC. o PF_KEY SADB was reworked: - now all security associations stored in the single SPI namespace, and all SAs MUST have unique SPI. - several hash tables added to speed up lookups in SADB. - SADB now uses rmlock to protect access, and concurrent threads can do SA lookups in the same time. - many PF_KEY message handlers were reworked to reflect changes in SADB. - SADB_UPDATE message was extended to support new PF_KEY headers: SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST. They can be used by IKE daemon to change SA addresses. o ipsecrequest and secpolicy structures were cardinally changed to avoid locking protection for ipsecrequest. Now we support only limited number (4) of bundled SAs, but they are supported for both INET and INET6. o INPCB security policy cache was introduced. Each PCB now caches used security policies to avoid SP lookup for each packet. o For inbound security policies added the mode, when the kernel does check for full history of applied IPsec transforms. o References counting rules for security policies and security associations were changed. The proper SA locking added into xform code. o xform code was also changed. Now it is possible to unregister xforms. tdb_xxx structures were changed and renamed to reflect changes in SADB/SPDB, and changed rules for locking and refcounting. Reviewed by: gnn, wblock Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D9352
2017-02-06 08:49:57 +00:00
# This requires the use of 'device crypto' and either 'options IPSEC' or
# 'options IPSEC_SUPPORT'.
options TCP_SIGNATURE #include support for RFC 2385
# DUMMYNET enables the "dummynet" bandwidth limiter. You need IPFIREWALL
# as well. See dummynet(4) and ipfw(8) for more info. When you run
# DUMMYNET, HZ/kern.hz should be at least 1000 for adequate response.
options DUMMYNET
1998-12-22 20:44:13 +00:00
# The DEBUGNET option enables a basic debug/panic-time networking API. It
# is used by NETDUMP and NETGDB.
options DEBUGNET
# The NETDUMP option enables netdump(4) client support in the kernel.
# This allows a panicking kernel to transmit a kernel dump to a remote host.
options NETDUMP
# The NETGDB option enables netgdb(4) support in the kernel. This allows a
# panicking kernel to be debugged as a GDB remote over the network.
options NETGDB
Split out a more generic debugnet(4) from netdump(4) Debugnet is a simplistic and specialized panic- or debug-time reliable datagram transport. It can drive a single connection at a time and is currently unidirectional (debug/panic machine transmit to remote server only). It is mostly a verbatim code lift from netdump(4). Netdump(4) remains the only consumer (until the rest of this patch series lands). The INET-specific logic has been extracted somewhat more thoroughly than previously in netdump(4), into debugnet_inet.c. UDP-layer logic and up, as much as possible as is protocol-independent, remains in debugnet.c. The separation is not perfect and future improvement is welcome. Supporting INET6 is a long-term goal. Much of the diff is "gratuitous" renaming from 'netdump_' or 'nd_' to 'debugnet_' or 'dn_' -- sorry. I thought keeping the netdump name on the generic module would be more confusing than the refactoring. The only functional change here is the mbuf allocation / tracking. Instead of initiating solely on netdump-configured interface(s) at dumpon(8) configuration time, we watch for any debugnet-enabled NIC for link activation and query it for mbuf parameters at that time. If they exceed the existing high-water mark allocation, we re-allocate and track the new high-water mark. Otherwise, we leave the pre-panic mbuf allocation alone. In a future patch in this series, this will allow initiating netdump from panic ddb(4) without pre-panic configuration. No other functional change intended. Reviewed by: markj (earlier version) Some discussion with: emaste, jhb Objection from: marius Differential Revision: https://reviews.freebsd.org/D21421
2019-10-17 16:23:03 +00:00
#####################################################################
# FILESYSTEM OPTIONS
#
# Only the root filesystem needs to be statically compiled or preloaded
# as module; everything else will be automatically loaded at mount
# time. Some people still prefer to statically compile other
# filesystems as well.
#
# NB: The UNION filesystem was known to be buggy in the past. It is now
# being actively maintained, although there are still some issues being
# resolved.
#
# One of these is mandatory:
options FFS #Fast filesystem
options NFSCL #Network File System client
1994-08-28 06:46:25 +00:00
# The rest are optional:
options AUTOFS #Automounter filesystem
options CD9660 #ISO 9660 filesystem
options FDESCFS #File descriptor filesystem
options FUSEFS #FUSEFS support module
options MSDOSFS #MS DOS File System (FAT, FAT32)
options NFSLOCKD #Network Lock Manager
options NFSD #Network Filesystem Server
options KGSSAPI #Kernel GSSAPI implementation
options NULLFS #NULL filesystem
2001-12-04 01:35:59 +00:00
options PROCFS #Process filesystem (requires PSEUDOFS)
options PSEUDOFS #Pseudo-filesystem framework
2005-03-14 16:04:27 +00:00
options PSEUDOFS_TRACE #Debugging support for PSEUDOFS
options SMBFS #SMB/CIFS filesystem
2011-02-10 05:33:40 +00:00
options TMPFS #Efficient memory filesystem
options UDF #Universal Disk Format
options UNIONFS #Union filesystem
# The xFS_ROOT options REQUIRE the associated ``options xFS''
options NFS_ROOT #NFS usable as root device
1994-08-28 06:46:25 +00:00
2002-05-16 21:28:32 +00:00
# Soft updates is a technique for improving filesystem speed and
# making abrupt shutdown less risky.
#
options SOFTUPDATES
# Extended attributes allow additional data to be associated with files,
# and is used for ACLs, Capabilities, and MAC labels.
# See src/sys/ufs/ufs/README.extattr for more information.
options UFS_EXTATTR
options UFS_EXTATTR_AUTOSTART
# Access Control List support for UFS filesystems. The current ACL
# implementation requires extended attribute support, UFS_EXTATTR,
# for the underlying filesystem.
# See src/sys/ufs/ufs/README.acls for more information.
options UFS_ACL
# Directory hashing improves the speed of operations on very large
# directories at the expense of some memory.
options UFS_DIRHASH
# Gjournal-based UFS journaling support.
options UFS_GJOURNAL
# Make space in the kernel for a root filesystem on a md device.
# Define to the number of kilobytes to reserve for the filesystem.
# This is now optional.
# If not defined, the root filesystem passed in as the MFS_IMAGE makeoption
# will be automatically embedded in the kernel during linking. Its exact size
# will be consumed within the kernel.
# If defined, the old way of embedding the filesystem in the kernel will be
# used. That is to say MD_ROOT_SIZE KB will be allocated in the kernel and
# later, the filesystem image passed in as the MFS_IMAGE makeoption will be
# dd'd into the reserved space if it fits.
options MD_ROOT_SIZE=10
# Make the md device a potential root device, either with preloaded
# images of type mfs_root or md_root.
options MD_ROOT
1995-04-25 03:44:04 +00:00
# Write-protect the md root device so that it may not be mounted writeable.
options MD_ROOT_READONLY
# Allow to read MD image from external memory regions
options MD_ROOT_MEM
# Disk quotas are supported when this option is enabled.
options QUOTA #enable disk quotas
# If you are running a machine just as a fileserver for PC and MAC
# users, using SAMBA, you may consider setting this option
# and keeping all those users' directories on a filesystem that is
# mounted with the suiddir option. This gives new files the same
# ownership as the directory (similar to group). It's a security hole
# if you let these users run programs, so confine it to file-servers
# (but it'll save you lots of headaches in those cases). Root owned
# directories are exempt and X bits are cleared. The suid bit must be
# set on the directory as well; see chmod(1). PC owners can't see/set
# ownerships so they keep getting their toes trodden on. This saves
# you all the support calls as the filesystem it's used on will act as
# they expect: "It's my dir so it must be my file".
#
options SUIDDIR
# NFS options:
options NFS_MINATTRTIMO=3 # VREG attrib cache timeout in sec
options NFS_MAXATTRTIMO=60
options NFS_MINDIRATTRTIMO=30 # VDIR attrib cache timeout in sec
options NFS_MAXDIRATTRTIMO=60
options NFS_DEBUG # Enable NFS Debugging
#
# Add support for the EXT2FS filesystem of Linux fame. Be a bit
# careful with this - the ext2fs code has a tendency to lag behind
# changes and not be exercised very much, so mounting read/write could
# be dangerous (and even mounting read only could result in panics.)
#
options EXT2FS
# The system memory devices; /dev/mem, /dev/kmem
2010-12-28 22:44:32 +00:00
device mem
# The kernel symbol table device; /dev/ksyms
device ksyms
# Optional character code conversion support with LIBICONV.
# Each option requires their base file system and LIBICONV.
options CD9660_ICONV
options MSDOSFS_ICONV
options UDF_ICONV
#####################################################################
# POSIX P1003.1B
2006-08-24 08:00:02 +00:00
# Real time extensions added in the 1993 POSIX
# _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING
options _KPOSIX_PRIORITY_SCHEDULING
2002-10-07 04:09:16 +00:00
# p1003_1b_semaphores are very experimental,
# user should be ready to assist in debugging if problems arise.
options P1003_1B_SEMAPHORES
# POSIX message queue
options P1003_1B_MQUEUE
#####################################################################
# SECURITY POLICY PARAMETERS
# Support for BSM audit
options AUDIT
# Support for Mandatory Access Control (MAC):
options MAC
options MAC_BIBA
options MAC_BSDEXTENDED
mac: add new mac_ddb(4) policy Generally, access to the kernel debugger is considered to be unsafe from a security perspective since it presents an unrestricted interface to inspect or modify the system state, including sensitive data such as signing keys. However, having some access to debugger functionality on production systems may be useful in determining the cause of a panic or hang. Therefore, it is desirable to have an optional policy which allows limited use of ddb(4) while disabling the functionality which could reveal system secrets. This loadable MAC module allows for the use of some ddb(4) commands while preventing the execution of others. The commands have been broadly grouped into three categories: - Those which are 'safe' and will not emit sensitive data (e.g. trace). Generally, these commands are deterministic and don't accept arguments. - Those which are definitively unsafe (e.g. examine <addr>, search <addr> <value>) - Commands which may be safe to execute depending on the arguments provided (e.g. show thread <addr>). Safe commands have been flagged as such with the DB_CMD_MEMSAFE flag. Commands requiring extra validation can provide a function to do so. For example, 'show thread <addr>' can be used as long as addr can be checked against the system's list of process structures. The policy also prevents debugger backends other than ddb(4) from executing, for example gdb(4). Reviewed by: markj, pauamma_gundo.com (manpages) Sponsored by: Juniper Networks, Inc. Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D35371
2022-07-18 21:24:06 +00:00
options MAC_DDB
options MAC_IFOFF
options MAC_IPACL
options MAC_LOMAC
options MAC_MLS
options MAC_NONE
options MAC_NTPD
options MAC_PARTITION
options MAC_PORTACL
options MAC_PRIORITY
options MAC_SEEOTHERUIDS
options MAC_STUB
options MAC_TEST
options MAC_VERIEXEC
options MAC_VERIEXEC_SHA1
options MAC_VERIEXEC_SHA256
options MAC_VERIEXEC_SHA384
options MAC_VERIEXEC_SHA512
device mac_veriexec_parser
# Support for Capsicum
options CAPABILITIES # fine-grained rights on file descriptors
options CAPABILITY_MODE # sandboxes with no global namespace access
#####################################################################
# CLOCK OPTIONS
# The granularity of operation is controlled by the kernel option HZ (default
# frequency of 1000 Hz or a period 1ms between calls). Virtual machine guests
# use a value of 100. Lower values may lower overhead at the expense of accuracy
# of scheduling, though the adaptive tick code reduces that overhead.
options HZ=100
# Enable support for the kernel PLL to use an external PPS signal,
# under supervision of [x]ntpd(8)
# More info in ntpd documentation: http://www.eecis.udel.edu/~ntp
options PPS_SYNC
# Enable support for generic feed-forward clocks in the kernel.
# The feed-forward clock support is an alternative to the feedback oriented
# ntpd/system clock approach, and is to be used with a feed-forward
# synchronization algorithm such as the RADclock:
# More info here: http://www.synclab.org/radclock
options FFCLOCK
#####################################################################
1995-03-15 14:27:01 +00:00
# SCSI DEVICES
# SCSI DEVICE CONFIGURATION
# The SCSI subsystem consists of the `base' SCSI code, a number of
# high-level SCSI device `type' drivers, and the low-level host-adapter
# device drivers. The host adapters are listed in the ISA and PCI
# device configuration sections below.
#
# It is possible to wire down your SCSI devices so that a given bus,
# target, and LUN always come on line as the same device unit. In
# earlier versions the unit numbers were assigned in the order that
# the devices were probed on the SCSI bus. This means that if you
# removed a disk drive, you may have had to rewrite your /etc/fstab
# file, and also that you had to be careful when adding a new disk
# as it may have been probed earlier and moved your device configuration
# around.
# This old behavior is maintained as the default behavior. The unit
# assignment begins with the first non-wired down unit for a device
# type. For example, if you wire a disk as "da3" then the first
# non-wired disk will be assigned da4.
# The syntax for wiring down devices is:
envvar hint.scbus.0.at="ahc0"
envvar hint.scbus.1.at="ahc1"
envvar hint.scbus.1.bus="0"
envvar hint.scbus.3.at="ahc2"
envvar hint.scbus.3.bus="0"
envvar hint.scbus.2.at="ahc2"
envvar hint.scbus.2.bus="1"
envvar hint.da.0.at="scbus0"
envvar hint.da.0.target="0"
envvar hint.da.0.unit="0"
envvar hint.da.1.at="scbus3"
envvar hint.da.1.target="1"
envvar hint.da.2.at="scbus2"
envvar hint.da.2.target="3"
envvar hint.sa.1.at="scbus1"
envvar hint.sa.1.target="6"
# "units" (SCSI logical unit number) that are not specified are
# treated as if specified as LUN 0.
# All SCSI devices allocate as many units as are required.
# The ch driver drives SCSI Media Changer ("jukebox") devices.
#
# The da driver drives SCSI Direct Access ("disk") and Optical Media
# ("WORM") devices.
#
# The sa driver drives SCSI Sequential Access ("tape") devices.
#
# The cd driver drives SCSI Read Only Direct Access ("cd") devices.
#
2004-06-26 17:19:44 +00:00
# The ses driver drives SCSI Environment Services ("ses") and
# SAF-TE ("SCSI Accessible Fault-Tolerant Enclosure") devices.
#
# The pt driver drives SCSI Processor devices.
#
# The sg driver provides a passthrough API that is compatible with the
# Linux SG driver. It will work in conjunction with the Linuxulator
# to run linux SG apps. It can also stand on its own and provide
# source level API compatibility for porting apps to FreeBSD.
2004-01-25 12:32:56 +00:00
#
# Target Mode support is provided here but also requires that a SIM
# (SCSI Host Adapter Driver) provide support as well.
#
# The targ driver provides target mode support as a Processor type device.
# It exists to give the minimal context necessary to respond to Inquiry
# commands. There is a sample user application that shows how the rest
# of the command support might be done in /usr/share/examples/scsi_target.
#
# The targbh driver provides target mode support and exists to respond
# to incoming commands that do not otherwise have a logical unit assigned
# to them.
2004-01-25 12:32:56 +00:00
#
# The pass driver provides a passthrough API to access the CAM subsystem.
device scbus #base SCSI code
device ch #SCSI media changers
device da #SCSI direct access devices (aka disks)
device sa #SCSI tapes
device cd #SCSI CD-ROMs
device ses #Enclosure Services (SES and SAF-TE)
2004-01-25 12:32:56 +00:00
device pt #SCSI processor
device targ #SCSI Target Mode Code
device targbh #SCSI Target Mode Blackhole Device
device pass #CAM passthrough driver
device sg #Linux SCSI passthrough
Add the CAM Target Layer (CTL). CTL is a disk and processor device emulation subsystem originally written for Copan Systems under Linux starting in 2003. It has been shipping in Copan (now SGI) products since 2005. It was ported to FreeBSD in 2008, and thanks to an agreement between SGI (who acquired Copan's assets in 2010) and Spectra Logic in 2010, CTL is available under a BSD-style license. The intent behind the agreement was that Spectra would work to get CTL into the FreeBSD tree. Some CTL features: - Disk and processor device emulation. - Tagged queueing - SCSI task attribute support (ordered, head of queue, simple tags) - SCSI implicit command ordering support. (e.g. if a read follows a mode select, the read will be blocked until the mode select completes.) - Full task management support (abort, LUN reset, target reset, etc.) - Support for multiple ports - Support for multiple simultaneous initiators - Support for multiple simultaneous backing stores - Persistent reservation support - Mode sense/select support - Error injection support - High Availability support (1) - All I/O handled in-kernel, no userland context switch overhead. (1) HA Support is just an API stub, and needs much more to be fully functional. ctl.c: The core of CTL. Command handlers and processing, character driver, and HA support are here. ctl.h: Basic function declarations and data structures. ctl_backend.c, ctl_backend.h: The basic CTL backend API. ctl_backend_block.c, ctl_backend_block.h: The block and file backend. This allows for using a disk or a file as the backing store for a LUN. Multiple threads are started to do I/O to the backing device, primarily because the VFS API requires that to get any concurrency. ctl_backend_ramdisk.c: A "fake" ramdisk backend. It only allocates a small amount of memory to act as a source and sink for reads and writes from an initiator. Therefore it cannot be used for any real data, but it can be used to test for throughput. It can also be used to test initiators' support for extremely large LUNs. ctl_cmd_table.c: This is a table with all 256 possible SCSI opcodes, and command handler functions defined for supported opcodes. ctl_debug.h: Debugging support. ctl_error.c, ctl_error.h: CTL-specific wrappers around the CAM sense building functions. ctl_frontend.c, ctl_frontend.h: These files define the basic CTL frontend port API. ctl_frontend_cam_sim.c: This is a CTL frontend port that is also a CAM SIM. This frontend allows for using CTL without any target-capable hardware. So any LUNs you create in CTL are visible in CAM via this port. ctl_frontend_internal.c, ctl_frontend_internal.h: This is a frontend port written for Copan to do some system-specific tasks that required sending commands into CTL from inside the kernel. This isn't entirely relevant to FreeBSD in general, but can perhaps be repurposed. ctl_ha.h: This is a stubbed-out High Availability API. Much more is needed for full HA support. See the comments in the header and the description of what is needed in the README.ctl.txt file for more details. ctl_io.h: This defines most of the core CTL I/O structures. union ctl_io is conceptually very similar to CAM's union ccb. ctl_ioctl.h: This defines all ioctls available through the CTL character device, and the data structures needed for those ioctls. ctl_mem_pool.c, ctl_mem_pool.h: Generic memory pool implementation used by the internal frontend. ctl_private.h: Private data structres (e.g. CTL softc) and function prototypes. This also includes the SCSI vendor and product names used by CTL. ctl_scsi_all.c, ctl_scsi_all.h: CTL wrappers around CAM sense printing functions. ctl_ser_table.c: Command serialization table. This defines what happens when one type of command is followed by another type of command. ctl_util.c, ctl_util.h: CTL utility functions, primarily designed to be used from userland. See ctladm for the primary consumer of these functions. These include CDB building functions. scsi_ctl.c: CAM target peripheral driver and CTL frontend port. This is the path into CTL for commands from target-capable hardware/SIMs. README.ctl.txt: CTL code features, roadmap, to-do list. usr.sbin/Makefile: Add ctladm. ctladm/Makefile, ctladm/ctladm.8, ctladm/ctladm.c, ctladm/ctladm.h, ctladm/util.c: ctladm(8) is the CTL management utility. It fills a role similar to camcontrol(8). It allow configuring LUNs, issuing commands, injecting errors and various other control functions. usr.bin/Makefile: Add ctlstat. ctlstat/Makefile ctlstat/ctlstat.8, ctlstat/ctlstat.c: ctlstat(8) fills a role similar to iostat(8). It reports I/O statistics for CTL. sys/conf/files: Add CTL files. sys/conf/NOTES: Add device ctl. sys/cam/scsi_all.h: To conform to more recent specs, the inquiry CDB length field is now 2 bytes long. Add several mode page definitions for CTL. sys/cam/scsi_all.c: Handle the new 2 byte inquiry length. sys/dev/ciss/ciss.c, sys/dev/ata/atapi-cam.c, sys/cam/scsi/scsi_targ_bh.c, scsi_target/scsi_cmds.c, mlxcontrol/interface.c: Update for 2 byte inquiry length field. scsi_da.h: Add versions of the format and rigid disk pages that are in a more reasonable format for CTL. amd64/conf/GENERIC, i386/conf/GENERIC, ia64/conf/GENERIC, sparc64/conf/GENERIC: Add device ctl. i386/conf/PAE: The CTL frontend SIM at least does not compile cleanly on PAE. Sponsored by: Copan Systems, SGI and Spectra Logic MFC after: 1 month
2012-01-12 00:34:33 +00:00
device ctl #CAM Target Layer
# CAM OPTIONS:
# debugging options:
# CAMDEBUG Compile in all possible debugging.
# CAM_DEBUG_COMPILE Debug levels to compile in.
# CAM_DEBUG_FLAGS Debug levels to enable on boot.
# CAM_DEBUG_BUS Limit debugging to the given bus.
# CAM_DEBUG_TARGET Limit debugging to the given target.
# CAM_DEBUG_LUN Limit debugging to the given lun.
# CAM_DEBUG_DELAY Delay in us after printing each debug line.
# CAM_IO_STATS Publish additional CAM device statics by sysctl
#
# CAM_MAX_HIGHPOWER: Maximum number of concurrent high power (start unit) cmds
# SCSI_NO_SENSE_STRINGS: When defined disables sense descriptions
# SCSI_NO_OP_STRINGS: When defined disables opcode descriptions
# SCSI_DELAY: The number of MILLISECONDS to freeze the SIM (scsi adapter)
# queue after a bus reset, and the number of milliseconds to
# freeze the device queue after a bus device reset. This
# can be changed at boot and runtime with the
# kern.cam.scsi_delay tunable/sysctl.
options CAMDEBUG
options CAM_DEBUG_COMPILE=-1
options CAM_DEBUG_FLAGS=(CAM_DEBUG_INFO|CAM_DEBUG_PROBE|CAM_DEBUG_PERIPH)
options CAM_DEBUG_BUS=-1
options CAM_DEBUG_TARGET=-1
options CAM_DEBUG_LUN=-1
options CAM_DEBUG_DELAY=1
options CAM_MAX_HIGHPOWER=4
options SCSI_NO_SENSE_STRINGS
options SCSI_NO_OP_STRINGS
options SCSI_DELAY=5000 # Be pessimistic about Joe SCSI device
options CAM_IOSCHED_DYNAMIC
options CAM_IO_STATS
options CAM_TEST_FAILURE
# Options for the CAM CDROM driver:
# CHANGER_MIN_BUSY_SECONDS: Guaranteed minimum time quantum for a changer LUN
# CHANGER_MAX_BUSY_SECONDS: Maximum time quantum per changer LUN, only
# enforced if there is I/O waiting for another LUN
# The compiled in defaults for these variables are 2 and 10 seconds,
# respectively.
#
# These can also be changed on the fly with the following sysctl variables:
# kern.cam.cd.changer.min_busy_seconds
# kern.cam.cd.changer.max_busy_seconds
#
options CHANGER_MIN_BUSY_SECONDS=2
options CHANGER_MAX_BUSY_SECONDS=10
# Options for the CAM sequential access driver:
# SA_IO_TIMEOUT: Timeout for read/write/wfm operations, in minutes
# SA_SPACE_TIMEOUT: Timeout for space operations, in minutes
# SA_REWIND_TIMEOUT: Timeout for rewind operations, in minutes
# SA_ERASE_TIMEOUT: Timeout for erase operations, in minutes
1999-10-02 20:20:32 +00:00
# SA_1FM_AT_EOD: Default to model which only has a default one filemark at EOT.
options SA_IO_TIMEOUT=4
options SA_SPACE_TIMEOUT=60
options SA_REWIND_TIMEOUT=(2*60)
options SA_ERASE_TIMEOUT=(4*60)
options SA_1FM_AT_EOD
# Optional timeout for the CAM processor target (pt) device
# This is specified in seconds. The default is 60 seconds.
options SCSI_PT_DEFAULT_TIMEOUT=60
# Optional enable of doing SES passthrough on other devices (e.g., disks)
#
# Normally disabled because a lot of newer SCSI disks report themselves
# as having SES capabilities, but this can then clot up attempts to build
# a topology with the SES device that's on the box these drives are in....
options SES_ENABLE_PASSTHROUGH
#####################################################################
# MISCELLANEOUS DEVICES AND OPTIONS
Integrate the new MPSAFE TTY layer to the FreeBSD operating system. The last half year I've been working on a replacement TTY layer for the FreeBSD kernel. The new TTY layer was designed to improve the following: - Improved driver model: The old TTY layer has a driver model that is not abstract enough to make it friendly to use. A good example is the output path, where the device drivers directly access the output buffers. This means that an in-kernel PPP implementation must always convert network buffers into TTY buffers. If a PPP implementation would be built on top of the new TTY layer (still needs a hooks layer, though), it would allow the PPP implementation to directly hand the data to the TTY driver. - Improved hotplugging: With the old TTY layer, it isn't entirely safe to destroy TTY's from the system. This implementation has a two-step destructing design, where the driver first abandons the TTY. After all threads have left the TTY, the TTY layer calls a routine in the driver, which can be used to free resources (unit numbers, etc). The pts(4) driver also implements this feature, which means posix_openpt() will now return PTY's that are created on the fly. - Improved performance: One of the major improvements is the per-TTY mutex, which is expected to improve scalability when compared to the old Giant locking. Another change is the unbuffered copying to userspace, which is both used on TTY device nodes and PTY masters. Upgrading should be quite straightforward. Unlike previous versions, existing kernel configuration files do not need to be changed, except when they reference device drivers that are listed in UPDATING. Obtained from: //depot/projects/mpsafetty/... Approved by: philip (ex-mentor) Discussed: on the lists, at BSDCan, at the DevSummit Sponsored by: Snow B.V., the Netherlands dcons(4) fixed by: kan
2008-08-20 08:31:58 +00:00
device pty #BSD-style compatibility pseudo ttys
2002-01-01 05:16:03 +00:00
device nmdm #back-to-back tty devices
Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others
2000-06-13 22:28:50 +00:00
device md #Memory/malloc disk
device snp #Snoop device - to look at pty/vty/etc..
device ccd #Concatenated disk driver
device firmware #firmware(9) support
# Kernel side iconv library
options LIBICONV
# Size of the kernel message buffer. Should be N * pagesize.
options MSGBUF_SIZE=40960
#####################################################################
# HARDWARE BUS CONFIGURATION
#
# PCI bus & PCI options:
#
device pci
Native PCI-express HotPlug support. PCI-express HotPlug support is implemented via bits in the slot registers of the PCI-express capability of the downstream port along with an interrupt that triggers when bits in the slot status register change. This is implemented for FreeBSD by adding HotPlug support to the PCI-PCI bridge driver which attaches to the virtual PCI-PCI bridges representing downstream ports on HotPlug slots. The PCI-PCI bridge driver registers an interrupt handler to receive HotPlug events. It also uses the slot registers to determine the current HotPlug state and drive an internal HotPlug state machine. For simplicty of implementation, the PCI-PCI bridge device detaches and deletes the child PCI device when a card is removed from a slot and creates and attaches a PCI child device when a card is inserted into the slot. The PCI-PCI bridge driver provides a bus_child_present which claims that child devices are present on HotPlug-capable slots only when a card is inserted. Rather than requiring a timeout in the RC for config accesses to not-present children, the pcib_read/write_config methods fail all requests when a card is not present (or not yet ready). These changes include support for various optional HotPlug capabilities such as a power controller, mechanical latch, electro-mechanical interlock, indicators, and an attention button. It also includes support for devices which require waiting for command completion events before initiating a subsequent HotPlug command. However, it has only been tested on ExpressCard systems which support surprise removal and have none of these optional capabilities. PCI-express HotPlug support is conditional on the PCI_HP option which is enabled by default on arm64, x86, and powerpc. Reviewed by: adrian, imp, vangyzen (older versions) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D6136
2016-05-05 22:26:23 +00:00
options PCI_HP # PCI-Express native HotPlug
2016-04-29 23:55:22 +00:00
options PCI_IOV # PCI SR-IOV support
#####################################################################
# HARDWARE DEVICE CONFIGURATION
# For ISA the required hints are listed.
# PCI, CardBus, and SD/MMC are self identifying buses, so
# no hints are needed.
#
# Mandatory devices:
#
# These options are valid for other keyboard drivers as well.
options KBD_DISABLE_KEYMAP_LOAD # refuse to load a keymap
options KBD_INSTALL_CDEV # install a CDEV entry in /dev
# Define keyboard latency (try 200/15 for a snappy interactive console)
options KBD_DELAY1=200 # define initial key delay
options KBD_DELAY2=15 # define key delay
device kbdmux # keyboard multiplexer
options KBDMUX_DFLT_KEYMAP # specify the built-in keymap
makeoptions KBDMUX_DFLT_KEYMAP=it.iso
options FB_DEBUG # Frame buffer debugging
# Enable experimental features of the syscons terminal emulator (teken).
options TEKEN_CONS25 # cons25-style terminal emulation
options TEKEN_UTF8 # UTF-8 output handling
# The vt video console driver.
device vt
options VT_ALT_TO_ESC_HACK=1 # Prepend ESC sequence to ALT keys
options VT_MAXWINDOWS=16 # Number of virtual consoles
options VT_TWOBUTTON_MOUSE # Use right mouse button to paste
# The following options set the maximum framebuffer size.
options VT_FB_MAX_HEIGHT=480
options VT_FB_MAX_WIDTH=640
# The following options will let you change the default vt terminal colors.
options TERMINAL_NORM_ATTR=(FG_GREEN|BG_BLACK)
options TERMINAL_KERN_ATTR=(FG_LIGHTRED|BG_BLACK)
#
# Optional devices:
#
#
# SCSI host adapters:
#
# aacraid: Adaptec by PMC RAID controllers, Series 6/7/8 and upcoming
# families. Container interface, CAM required.
# ahc: Adaptec 274x/284x/2910/293x/294x/394x/3950x/3960x/398X/4944/
# 19160x/29160x, aic7770/aic78xx
2002-06-06 16:35:58 +00:00
# ahd: Adaptec 29320/39320 Controllers.
# isp: Qlogic ISP 1020, 1040 and 1040B PCI SCSI host adapters,
# ISP 1240 Dual Ultra SCSI, ISP 1080 and 1280 (Dual) Ultra2,
# ISP 12160 Ultra3 SCSI,
2001-08-31 21:39:56 +00:00
# Qlogic ISP 2100 and ISP 2200 1Gb Fibre Channel host adapters.
# Qlogic ISP 2300 and ISP 2312 2Gb Fibre Channel host adapters.
# Qlogic ISP 2322 and ISP 6322 2Gb Fibre Channel host adapters.
2000-12-11 23:31:32 +00:00
# ispfw: Firmware module for Qlogic host adapters
# mpr: LSI-Logic MPT/Fusion Gen 3
# mps: LSI-Logic MPT/Fusion Gen 2
# mpt: LSI-Logic MPT/Fusion 53c1020 or 53c1030 Ultra4
# or FC9x9 Fibre Channel host adapters.
2000-09-03 12:29:51 +00:00
# sym: Symbios/Logic 53C8XX family of PCI-SCSI I/O processors:
2004-01-25 12:32:56 +00:00
# 53C810, 53C810A, 53C815, 53C825, 53C825A, 53C860, 53C875,
# 53C876, 53C885, 53C895, 53C895A, 53C896, 53C897, 53C1510D,
2000-09-03 12:29:51 +00:00
# 53C1010-33, 53C1010-66.
device aacraid
device ahc
2002-06-06 16:35:58 +00:00
device ahd
device isp
envvar hint.isp.0.disable="1"
envvar hint.isp.0.role="3"
envvar hint.isp.0.prefer_iomap="1"
envvar hint.isp.0.prefer_memmap="1"
envvar hint.isp.0.fwload_disable="1"
envvar hint.isp.0.ignore_nvram="1"
envvar hint.isp.0.fullduplex="1"
envvar hint.isp.0.topology="lport"
envvar hint.isp.0.topology="nport"
envvar hint.isp.0.topology="lport-only"
envvar hint.isp.0.topology="nport-only"
2001-03-03 19:39:15 +00:00
# we can't get u_int64_t types, nor can we get strings if it's got
# a leading 0x, hence this silly dodge.
envvar hint.isp.0.portwnn="w50000000aaaa0000"
envvar hint.isp.0.nodewnn="w50000000aaaa0001"
device ispfw
device mpr # LSI-Logic MPT-Fusion 3
device mps # LSI-Logic MPT-Fusion 2
device mpt # LSI-Logic MPT-Fusion
device sym
# The aic7xxx driver will attempt to use memory mapped I/O for all PCI
# controllers that have it configured only if this option is set. Unfortunately,
# this doesn't work on some motherboards, which prevents it from being the
# default.
options AHC_ALLOW_MEMIO
2000-11-08 10:01:45 +00:00
# Dump the contents of the ahc controller configuration PROM.
options AHC_DUMP_EEPROM
# Bitmap of units to enable targetmode operations.
options AHC_TMODE_ENABLE
# Compile in Aic7xxx Debugging code.
2004-09-03 06:32:11 +00:00
options AHC_DEBUG
# Aic7xxx driver debugging options. See sys/dev/aic7xxx/aic7xxx.h
2004-09-03 06:32:11 +00:00
options AHC_DEBUG_OPTS
# Print register bitfields in debug output. Adds ~128k to driver
# See ahc(4).
2004-09-03 06:32:11 +00:00
options AHC_REG_PRETTY_PRINT
2002-06-06 16:35:58 +00:00
# Compile in aic79xx debugging code.
options AHD_DEBUG
2002-06-06 16:35:58 +00:00
# Aic79xx driver debugging options. Adds ~215k to driver. See ahd(4).
options AHD_DEBUG_OPTS=0xFFFFFFFF
2002-06-06 16:35:58 +00:00
2002-09-01 22:50:08 +00:00
# Print human-readable register definitions when debugging
options AHD_REG_PRETTY_PRINT
2002-09-01 22:50:08 +00:00
# Bitmap of units to enable targetmode operations.
2004-09-03 06:32:11 +00:00
options AHD_TMODE_ENABLE
# Options used in dev/iscsi (Software iSCSI stack)
#
options ISCSI_INITIATOR_DEBUG=9
# Options used in dev/isp/ (Qlogic SCSI/FC driver).
#
# ISP_TARGET_MODE - enable target mode operation
#
options ISP_TARGET_MODE=1
#
# ISP_DEFAULT_ROLES - default role
# none=0
# target=1
# initiator=2
# both=3 (not supported currently)
#
# ISP_INTERNAL_TARGET (trivial internal disk target, for testing)
#
options ISP_DEFAULT_ROLES=0
#options SYM_SETUP_SCSI_DIFF #-HVD support for 825a, 875, 885
# disabled:0 (default), enabled:1
#options SYM_SETUP_PCI_PARITY #-PCI parity checking
# disabled:0, enabled:1 (default)
#options SYM_SETUP_MAX_LUN #-Number of LUNs supported
# default:8, range:[1..64]
#
# Compaq "CISS" RAID controllers (SmartRAID 5* series)
# These controllers have a SCSI-like interface, and require the
# CAM infrastructure.
#
device ciss
#
# Compaq Smart RAID, Mylex DAC960 and AMI MegaRAID controllers. Only
# one entry is needed; the code will find and configure all supported
# controllers.
#
device ida # Compaq Smart RAID
device mlx # Mylex DAC960
2006-03-29 09:57:22 +00:00
device mfi # LSI MegaRAID SAS
device mfip # LSI MegaRAID SAS passthrough, requires CAM
2006-10-21 04:13:20 +00:00
options MFI_DEBUG
device mrsas # LSI/Avago MegaRAID SAS/SATA, 6Gb/s and 12Gb/s
#
# Serial ATA host controllers:
#
# ahci: Advanced Host Controller Interface (AHCI) compatible
# mvs: Marvell 88SX50XX/88SX60XX/88SX70XX/SoC controllers
# siis: SiliconImage SiI3124/SiI3132/SiI3531 controllers
#
# These drivers are part of cam(4) subsystem. They supersede less featured
# ata(4) subsystem drivers, supporting same hardware.
device ahci
device mvs
device siis
Finally!! The much roumored replacement for our current IDE/ATA/ATAPI is materialising in the CVS repositories around the globe. So what does this bring us: A new reengineered ATA/ATAPI subsystem, that tries to overcome most of the deficiencies with the current drivers. It supports PCI as well as ISA devices without all the hackery in ide_pci.c to make PCI devices look like ISA counterparts. It doesn't have the excessive wait problem on probe, in fact you shouldn't notice any delay when your devices are getting probed. Probing and attaching of devices are postponed until interrupts are enabled (well almost, not finished yet for disks), making things alot cleaner. Improved performance, although DMA support is still WIP and not in this pre alpha release, worldstone is faster with the new driver compared to the old even with DMA. So what does it take away: There is NO support for old MFM/RLL/ESDI disks. There is NO support for bad144, if your disk is bad, ditch it, it has already outgrown its internal spare sectors, and is dying. For you to try this out, you will have to modify your kernel config file to use the "ata" controller instead of all wdc? entries. example: # for a PCI only system (most modern machines) controller ata0 device atadisk0 # ATA disks device atapicd0 # ATAPI CDROM's device atapist0 # ATAPI tapes #You should add the following on ISA systems: controller ata1 at isa? port "IO_WD1" bio irq 14 controller ata2 at isa? port "IO_WD2" bio irq 15 You can leave it all in there, the system knows how to manage. For now this driver reuses the device entries from the old system (that will probably change later), but remember that disks are now numbered in the sequence they are found (like the SCSI system) not as absolute positions as the old system. Although I have tested this on all the systems I can get my hands on, there might very well be gremlins in there, so use AT YOU OWN RISK!! This is still WIP, so there are lots of rough edges and unfinished things in there, and what I have in my lab might look very different from whats in CVS at any given time. So please have all eventual changes go through me, or chances are they just dissapears... I would very much like to hear from you, both good and bad news are very welcome. Enjoy!! -Søren
1999-03-01 21:19:19 +00:00
#
# The 'ATA' driver supports all legacy ATA/ATAPI controllers, including
# PC Card devices. You only need one "device ata" for it to find all
2000-08-13 14:25:33 +00:00
# PCI and PC Card ATA/ATAPI devices on modern machines.
# Alternatively, individual bus and chipset drivers may be chosen by using
# the 'atacore' driver then selecting the drivers on a per vendor basis.
# For example to build a system which only supports a VIA chipset,
# omit 'ata' and include the 'atacore', 'atapci' and 'atavia' drivers.
device ata
# Modular ATA
#device atacore # Core ATA functionality
#device ataisa # ISA bus support
#device atapci # PCI bus support; only generic chipset support
# PCI ATA chipsets
#device ataacard # ACARD
#device ataacerlabs # Acer Labs Inc. (ALI)
#device ataamd # American Micro Devices (AMD)
#device ataati # ATI
#device atacenatek # Cenatek
#device atacypress # Cypress
#device atacyrix # Cyrix
#device atahighpoint # HighPoint
#device ataintel # Intel
#device ataite # Integrated Technology Inc. (ITE)
#device atajmicron # JMicron
#device atamarvell # Marvell
#device atamicron # Micron
#device atanational # National
#device atanetcell # NetCell
#device atanvidia # nVidia
#device atapromise # Promise
#device ataserverworks # ServerWorks
#device atasiliconimage # Silicon Image Inc. (SiI) (formerly CMD)
#device atasis # Silicon Integrated Systems Corp.(SiS)
#device atavia # VIA Technologies Inc.
2000-08-13 14:25:33 +00:00
#
# For older non-PCI, non-PnPBIOS systems, these are the hints lines to add:
envvar hint.ata.0.at="isa"
envvar hint.ata.0.port="0x1f0"
envvar hint.ata.0.irq="14"
envvar hint.ata.1.at="isa"
envvar hint.ata.1.port="0x170"
envvar hint.ata.1.irq="15"
2000-08-13 14:25:33 +00:00
#
# uart: generic driver for serial interfaces.
#
device uart
# Options for uart(4)
options UART_PPS_ON_CTS # Do time pulse capturing using CTS
# instead of DCD.
options UART_POLL_FREQ # Set polling rate, used when hw has
# no interrupt support (50 Hz default).
# The following hint should only be used for pure ISA devices. It is not
# needed otherwise. Use of hints is strongly discouraged.
envvar hint.uart.0.at="isa"
# The following 3 hints are used when the UART is a system device (i.e., a
# console or debug port), but only on platforms that don't have any other
# means to pass the information to the kernel. The unit number of the hint
# is only used to bundle the hints together. There is no relation to the
# unit number of the probed UART.
envvar hint.uart.0.port="0x3f8"
envvar hint.uart.0.flags="0x10"
envvar hint.uart.0.baud="115200"
# `flags' for serial drivers that support consoles, like uart(4):
# 0x10 enable console support for this unit. Other console flags
# (if applicable) are ignored unless this is set. Enabling
# console support does not make the unit the preferred console.
# Boot with -h or set boot_serial=YES in the loader.
# Currently, at most one unit can have console support; the
# first one (in config file order) with this flag set is
# preferred.
# 0x80 use this port for serial line gdb support in ddb. Also known
# as debug port.
#
# Options for serial drivers that support consoles:
options BREAK_TO_DEBUGGER # A BREAK/DBG on the console goes to
# ddb, if available.
# Solaris implements a new BREAK which is initiated by a character
# sequence CR ~ ^b which is similar to a familiar pattern used on
# Sun servers by the Remote Console. There are FreeBSD extensions:
# CR ~ ^p requests force panic and CR ~ ^r requests a clean reboot.
options ALT_BREAK_TO_DEBUGGER
# Serial Communications Controller
# Supports the Freescale/NXP QUad Integrated and Zilog Z8530 multi-channel
# communications controllers.
device scc
# PCI Universal Communications driver
# Supports various multi port PCI I/O cards.
device puc
#
# Network interfaces:
#
# MII bus support is required for many PCI Ethernet NICs,
# namely those which use MII-compliant transceivers or implement
# transceiver control interfaces that operate like an MII. Adding
# "device miibus" to the kernel config pulls in support for the generic
# miibus API, the common support for bit-bang'ing the MII and all
# of the PHY drivers, including a generic one for PHYs that aren't
# specifically handled by an individual driver. Support for specific
# PHYs may be built by adding "device mii", "device mii_bitbang" if
# needed by the NIC driver and then adding the appropriate PHY driver.
device mii # Minimal MII support
device mii_bitbang # Common module for bit-bang'ing the MII
device miibus # MII support w/ bit-bang'ing and all PHYs
device acphy # Altima Communications AC101
device amphy # AMD AM79c873 / Davicom DM910{1,2}
device atphy # Attansic/Atheros F1
device axphy # Asix Semiconductor AX88x9x
device bmtphy # Broadcom BCM5201/BCM5202 and 3Com 3c905C
device bnxt # Broadcom NetXtreme-C/NetXtreme-E
device brgphy # Broadcom BCM54xx/57xx 1000baseTX
device cgem # Cadence GEM Gigabit Ethernet
device ciphy # Cicada/Vitesse CS/VSC8xxx
device e1000phy # Marvell 88E1000 1000/100/10-BT
device gentbi # Generic 10-bit 1000BASE-{LX,SX} fiber ifaces
device icsphy # ICS ICS1889-1893
device ip1000phy # IC Plus IP1000A/IP1001
device jmphy # JMicron JMP211/JMP202
device lxtphy # Level One LXT-970
device nsgphy # NatSemi DP8361/DP83865/DP83891
device nsphy # NatSemi DP83840A
device nsphyter # NatSemi DP83843/DP83815
device pnaphy # HomePNA
device qsphy # Quality Semiconductor QS6612
device rdcphy # RDC Semiconductor R6040
device rgephy # RealTek 8169S/8110S/8211B/8211C
device rlphy # RealTek 8139
device rlswitch # RealTek 8305
device smcphy # SMSC LAN91C111
device tdkphy # TDK 89Q2120
device truephy # LSI TruePHY
device xmphy # XaQti XMAC II
# ae: Support for gigabit ethernet adapters based on the Attansic/Atheros
# L2 PCI-Express FastEthernet controllers.
2008-05-19 01:53:47 +00:00
# age: Support for gigabit ethernet adapters based on the Attansic/Atheros
# L1 PCI express gigabit ethernet controllers.
# alc: Support for Atheros AR8131/AR8132 PCIe ethernet controllers.
Add ale(4), a driver for Atheros AR8121/AR8113/AR8114 PCIe ethernet controller. The controller is also known as L1E(AR8121) and L2E(AR8113/AR8114). Unlike its predecessor Attansic L1, AR8121/AR8113/AR8114 uses completely different Rx logic such that it requires separate driver. Datasheet for AR81xx is not available to open source driver writers but it shares large part of Tx and PHY logic of L1. I still don't understand some part of register meaning and some MAC statistics counters but the driver seems to have no critical issues for performance and stability. The AR81xx requires copy operation to pass received frames to upper stack such that ale(4) consumes a lot of CPU cycles than that of other controller. A couple of silicon bugs also adds more CPU cycles to address the known hardware bug. However, if you have fast CPU you can still saturate the link. Currently ale(4) supports the following hardware features. - MSI. - TCP Segmentation offload. - Hardware VLAN tag insertion/stripping with checksum offload. - Tx TCP/UDP checksum offload and Rx IP/TCP/UDP checksum offload. - Tx/Rx interrupt moderation. - Hardware statistics counters. - Jumbo frame. - WOL. AR81xx PCIe ethernet controllers are mainly found on ASUS EeePC or P5Q series of ASUS motherboards. Special thanks to Jeremy Chadwick who sent the hardware to me. Without his donation writing a driver for AR81xx would never have been possible. Big thanks to all people who reported feedback or tested patches. HW donated by: koitsu Tested by: bsam, Joao Barros <joao.barros <> gmail DOT com > Jan Henrik Sylvester <me <> janh DOT de > Ivan Brawley < ivan <> brawley DOT id DOT au >, CURRENT ML
2008-11-12 09:52:06 +00:00
# ale: Support for Atheros AR8121/AR8113/AR8114 PCIe ethernet controllers.
# ath: Atheros a/b/g WiFi adapters (requires ath_hal and wlan)
# bce: Broadcom NetXtreme II (BCM5706/BCM5708) PCI/PCIe Gigabit Ethernet
# adapters.
# bfe: Broadcom BCM4401 Ethernet adapter.
# bge: Support for gigabit ethernet adapters based on the Broadcom
# BCM570x family of controllers, including the 3Com 3c996-T,
# the Netgear GA302T, the SysKonnect SK-9D21 and SK-9D41, and
# the embedded gigE NICs on Dell PowerEdge 2550 servers.
# bnxt: Broadcom NetXtreme-C and NetXtreme-E PCIe 10/25/50G Ethernet adapters.
# bxe: Broadcom NetXtreme II (BCM5771X/BCM578XX) PCIe 10Gb Ethernet
# adapters.
# bwi: Broadcom BCM430* and BCM431* family of wireless adapters.
2010-03-03 21:40:44 +00:00
# bwn: Broadcom BCM43xx family of wireless adapters.
# cas: Sun Cassini/Cassini+ and National Semiconductor DP83065 Saturn
# cxgb: Chelsio T3 based 1GbE/10GbE PCIe Ethernet adapters.
# cxgbe:Chelsio T4, T5, and T6-based 1/10/25/40/100GbE PCIe Ethernet
# adapters.
# cxgbev: Chelsio T4, T5, and T6-based PCIe Virtual Functions.
# dc: Support for PCI fast ethernet adapters based on the DEC/Intel 21143
# and various workalikes including:
# the ADMtek AL981 Comet and AN985 Centaur, the ASIX Electronics
# AX88140A and AX88141, the Davicom DM9100 and DM9102, the Lite-On
# 82c168 and 82c169 PNIC, the Lite-On/Macronix LC82C115 PNIC II
# and the Macronix 98713/98713A/98715/98715A/98725 PMAC. This driver
# replaces the old al, ax, dm, pn and mx drivers. List of brands:
2004-01-25 12:32:56 +00:00
# Digital DE500-BA, Kingston KNE100TX, D-Link DFE-570TX, SOHOware SFA110,
# SVEC PN102-TX, CNet Pro110B, 120A, and 120B, Compex RL100-TX,
# LinkSys LNE100TX, LNE100TX V2.0, Jaton XpressNet, Alfa Inc GFC2204,
# KNE110TX.
# em: Intel Pro/1000 Gigabit Ethernet 82542, 82543, 82544 based adapters.
# fxp: Intel EtherExpress Pro/100B
2001-02-27 23:02:00 +00:00
# (hint of prefer_iomap can be done to prefer I/O instead of Mem mapping)
o Revert the part of if_gem.c rev. 1.35 which added a call to gem_stop() to gem_attach() as the former access softc members not yet initialized at that time and gem_reset() actually is enough to stop the chip. [1] o Revise the use of gem_bitwait(); add bus_barrier() calls before calling gem_bitwait() to ensure the respective bit has been written before we starting polling on it and poll for the right bits to change, f.e. even though we only reset RX we have to actually wait for both GEM_RESET_RX and GEM_RESET_TX to clear. Add some additional gem_bitwait() calls in places we've been missing them according to the GEM documentation. Along with this some excessive DELAYs, which probably only were added because of bugs in gem_bitwait() and its use in the first place, as well as as have of an gem_bitwait() reimplementation in gem_reset_tx() were removed. o Add gem_reset_rxdma() and use it to deal with GEM_MAC_RX_OVERFLOW errors more gracefully as unlike gem_init_locked() it resets the RX DMA engine only, causing no link loss and the FIFOs not to be cleared. Also use it deal with GEM_INTR_RX_TAG_ERR errors, with previously were unhandled. This was based on information obtained from the Linux GEM and OpenSolaris ERI drivers. o Turn on workarounds for silicon bugs in the Apple GMAC variants. This was based on information obtained from the Darwin GMAC and Linux GEM drivers. o Turn on "infinite" (i.e. maximum 31 * 64 bytes in length) DMA bursts. This greatly improves especially RX performance. o Optimize the RX path, this consists of: - kicking the receiver as soon as we've a spare descriptor in gem_rint() again instead of just once after all the ready ones have been handled; - kicking the receiver the right way, i.e. as outlined in the GEM documentation in batches of 4 and by pointing it to the descriptor after the last valid one; - calling gem_rint() before gem_tint() in gem_intr() as gem_tint() may take quite a while; - doubling the size of the RX ring to 256 descriptors. Overall the RX performance of a GEM in a 1GHz Sun Fire V210 was improved from ~100Mbit/s to ~850Mbit/s. o In gem_add_rxbuf() don't assign the newly allocated mbuf to rxs_mbuf before calling bus_dmamap_load_mbuf_sg(), if bus_dmamap_load_mbuf_sg() fails we'll free the newly allocated mbuf, unable to recycle the previous one but a NULL pointer dereference instead. o In gem_init_locked() honor the return value of gem_meminit(). o Simplify gem_ringsize() and dont' return garbage in the default case. Based on OpenBSD. o Don't turn on MAC control, MIF and PCS interrupts unless GEM_DEBUG is defined as we don't need/use these interrupts for operation. o In gem_start_locked() sync the DMA maps of the descriptor rings before every kick of the transmitter and not just once after enqueuing all packets as the NIC might instantly start transmitting after we kicked it the first time. o Keep state of the link state and use it to enable or disable the MAC in gem_mii_statchg() accordingly as well as to return early from gem_start_locked() in case the link is down. [3] o Initialize the maximum frame size to a sane value. o In gem_mii_statchg() enable carrier extension if appropriate. o Increment if_ierrors in case of an GEM_MAC_RX_OVERFLOW error and in gem_eint(). [3] o Handle IFF_ALLMULTI correctly; don't set it if we've turned promiscuous group mode on and don't clear the flag if we've disabled promiscuous group mode (these were mostly NOPs though). [2] o Let gem_eint() also report GEM_INTR_PERR errors. o Move setting sc_variant from gem_pci_probe() to gem_pci_attach() as device probe methods are not supposed to touch the softc. o Collapse sc_inited and sc_pci into bits for sc_flags. o Add CTASSERTs ensuring that GEM_NRXDESC and GEM_NTXDESC are set to legal values. o Correctly set up for 802.3x flow control, though #ifdef out the code that actually enables it as this needs more testing and mainly a proper framework to support it. o Correct and add some conversions from hard-coded functions names to __func__ which were borked or forgotten in if_gem.c rev. 1.42. o Use PCIR_BAR instead of a homegrown macro. o Replace sc_enaddr[6] with sc_enaddr[ETHER_ADDR_LEN]. o In gem_pci_attach() in case attaching fails release the resources in the opposite order they were allocated. o Make gem_reset() static to if_gem.c as it's not needed outside that module. o Remove the GEM_GIGABIT flag and the associated code; GEM_GIGABIT was never set and the associated code was in the wrong place. o Remove sc_mif_config; it was only used to cache the contents of the respective register within gem_attach(). o Remove the #ifdef'ed out NetBSD/OpenBSD code for establishing a suspend hook as it will never be used on FreeBSD. o Also probe Apple Intrepid 2 GMAC and Apple Shasta GMAC, add support for Apple K2 GMAC. Based on OpenBSD. o Add support for Sun GBE/P cards, or in other words actually add support for cards based on GEM to gem(4). This mainly consists of adding support for the TBI of these chips. Along with this the PHY selection code was rewritten to hardcode the PHY number for certain configurations as for example the PHY of the on-board ERI of Blade 1000 shows up twice causing no link as the second incarnation is isolated. These changes were ported from OpenBSD with some additional improvements and modulo some bugs. o Add code to if_gem_pci.c allowing to read the MAC-address from the VPD on systems without Open Firmware. This is an improved version of my variant of the respective code in if_hme_pci.c o Now that gem(4) is MI enable it for all archs. Pointed out by: yongari [1] Suggested by: rwatson [2], yongari [3] Tested on: i386 (GEM), powerpc (GMACs by marcel and yongari), sparc64 (ERI and GEM) Reviewed by: yongari Approved by: re (kensmith)
2007-09-26 21:14:18 +00:00
# gem: Apple GMAC/Sun ERI/Sun GEM
2008-05-27 01:54:45 +00:00
# jme: JMicron JMC260 Fast Ethernet/JMC250 Gigabit Ethernet based adapters.
# le: AMD Am7900 LANCE and Am79C9xx PCnet
# lge: Support for PCI gigabit ethernet adapters based on the Level 1
# LXT1001 NetCellerator chipset. This includes the D-Link DGE-500SX,
# SMC TigerCard 1000 (SMC9462SX), and some Addtron cards.
# lio: Support for Cavium 23XX Ethernet adapters
# malo: Marvell Libertas wireless NICs.
# mwl: Marvell 88W8363 802.11n wireless NICs.
# Requires the mwl firmware module
# mwlfw: Marvell 88W8363 firmware
2006-12-13 02:37:48 +00:00
# msk: Support for gigabit ethernet adapters based on the Marvell/SysKonnect
# Yukon II Gigabit controllers, including 88E8021, 88E8022, 88E8061,
# 88E8062, 88E8035, 88E8036, 88E8038, 88E8050, 88E8052, 88E8053,
# 88E8055, 88E8056 and D-Link 560T/550SX.
# mlxfw: Mellanox firmware update module.
# mlx5: Mellanox ConnectX-4 and ConnectX-4 LX IB and Eth shared code module.
# mlx5en:Mellanox ConnectX-4 and ConnectX-4 LX PCIe Ethernet adapters.
# my: Myson Fast Ethernet (MTD80X, MTD89X)
# nge: Support for PCI gigabit ethernet adapters based on the National
# Semiconductor DP83820 and DP83821 chipset. This includes the
# SMC EZ Card 1000 (SMC9462TX), D-Link DGE-500T, Asante FriendlyNet
# GigaNIX 1000TA and 1000TPC, the Addtron AEG320T, the Surecom
# EP-320G-TX and the Netgear GA622T.
# oce: Emulex 10 Gbit adapters (OneConnect Ethernet)
# ral: Ralink Technology IEEE 802.11 wireless adapter
# re: RealTek 8139C+/8169/816xS/811xS/8101E PCI/PCIe Ethernet adapter
# rl: Support for PCI fast ethernet adapters based on the RealTek 8129/8139
# chipset. Note that the RealTek driver defaults to using programmed
# I/O to do register accesses because memory mapped mode seems to cause
# severe lockups on SMP hardware. This driver also supports the
# Accton EN1207D `Cheetah' adapter, which uses a chip called
# the MPX 5030/5038, which is either a RealTek in disguise or a
# RealTek workalike. Note that the D-Link DFE-530TX+ uses the RealTek
# chipset and is supported by this driver, not the 'vr' driver.
2016-05-27 03:30:42 +00:00
# rtwn: RealTek wireless adapters.
# rtwnfw: RealTek wireless firmware.
# sge: Silicon Integrated Systems SiS190/191 Fast/Gigabit Ethernet adapter
# sis: Support for NICs based on the Silicon Integrated Systems SiS 900,
# SiS 7016 and NS DP83815 PCI fast ethernet controller chips.
# sk: Support for the SysKonnect SK-984x series PCI gigabit ethernet NICs.
# This includes the SK-9841 and SK-9842 single port cards (single mode
# and multimode fiber) and the SK-9843 and SK-9844 dual port cards
# (also single mode and multimode).
# The driver will autodetect the number of ports on the card and
# attach each one as a separate network interface.
# ste: Sundance Technologies ST201 PCI fast ethernet controller, includes
# the D-Link DFE-550TX.
2006-07-25 00:45:55 +00:00
# stge: Support for gigabit ethernet adapters based on the Sundance/Tamarack
# TC9021 family of controllers, including the Sundance ST2021/ST2023,
# the Sundance/Tamarack TC9021, the D-Link DL-4000 and ASUS NX1101.
# ti: Support for PCI gigabit ethernet NICs based on the Alteon Networks
# Tigon 1 and Tigon 2 chipsets. This includes the Alteon AceNIC, the
# 3Com 3c985, the Netgear GA620 and various others. Note that you will
# probably want to bump up kern.ipc.nmbclusters a lot to use this driver.
# vr: Support for various fast ethernet adapters based on the VIA
# Technologies VT3043 `Rhine I' and VT86C100A `Rhine II' chips,
# including the D-Link DFE520TX and D-Link DFE530TX (see 'rl' for
# DFE530TX+), the Hawking Technologies PN102TX, and the AOpen/Acer ALN-320.
# vte: DM&P Vortex86 RDC R6040 Fast Ethernet
# xl: Support for the 3Com 3c900, 3c905, 3c905B and 3c905C (Fast)
# Etherlink XL cards and integrated controllers. This includes the
# integrated 3c905B-TX chips in certain Dell Optiplex and Dell
# Precision desktop machines and the integrated 3c905-TX chips
# in Dell Latitude laptop docking stations.
# Also supported: 3Com 3c980(C)-TX, 3Com 3cSOHO100-TX, 3Com 3c450-TX
# PCI Ethernet NICs that use the common MII bus controller code.
device ae # Attansic/Atheros L2 FastEthernet
2008-05-19 01:53:47 +00:00
device age # Attansic/Atheros L1 Gigabit Ethernet
device alc # Atheros AR8131/AR8132 Ethernet
Add ale(4), a driver for Atheros AR8121/AR8113/AR8114 PCIe ethernet controller. The controller is also known as L1E(AR8121) and L2E(AR8113/AR8114). Unlike its predecessor Attansic L1, AR8121/AR8113/AR8114 uses completely different Rx logic such that it requires separate driver. Datasheet for AR81xx is not available to open source driver writers but it shares large part of Tx and PHY logic of L1. I still don't understand some part of register meaning and some MAC statistics counters but the driver seems to have no critical issues for performance and stability. The AR81xx requires copy operation to pass received frames to upper stack such that ale(4) consumes a lot of CPU cycles than that of other controller. A couple of silicon bugs also adds more CPU cycles to address the known hardware bug. However, if you have fast CPU you can still saturate the link. Currently ale(4) supports the following hardware features. - MSI. - TCP Segmentation offload. - Hardware VLAN tag insertion/stripping with checksum offload. - Tx TCP/UDP checksum offload and Rx IP/TCP/UDP checksum offload. - Tx/Rx interrupt moderation. - Hardware statistics counters. - Jumbo frame. - WOL. AR81xx PCIe ethernet controllers are mainly found on ASUS EeePC or P5Q series of ASUS motherboards. Special thanks to Jeremy Chadwick who sent the hardware to me. Without his donation writing a driver for AR81xx would never have been possible. Big thanks to all people who reported feedback or tested patches. HW donated by: koitsu Tested by: bsam, Joao Barros <joao.barros <> gmail DOT com > Jan Henrik Sylvester <me <> janh DOT de > Ivan Brawley < ivan <> brawley DOT id DOT au >, CURRENT ML
2008-11-12 09:52:06 +00:00
device ale # Atheros AR8121/AR8113/AR8114 Ethernet
device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet
device bfe # Broadcom BCM440x 10/100 Ethernet
device bge # Broadcom BCM570xx Gigabit Ethernet
device cas # Sun Cassini/Cassini+ and NS DP83065 Saturn
device dc # DEC/Intel 21143 and various workalikes
device et # Agere ET1310 10/100/Gigabit Ethernet
device fxp # Intel EtherExpress PRO/100B (82557, 82558)
envvar hint.fxp.0.prefer_iomap="0"
o Revert the part of if_gem.c rev. 1.35 which added a call to gem_stop() to gem_attach() as the former access softc members not yet initialized at that time and gem_reset() actually is enough to stop the chip. [1] o Revise the use of gem_bitwait(); add bus_barrier() calls before calling gem_bitwait() to ensure the respective bit has been written before we starting polling on it and poll for the right bits to change, f.e. even though we only reset RX we have to actually wait for both GEM_RESET_RX and GEM_RESET_TX to clear. Add some additional gem_bitwait() calls in places we've been missing them according to the GEM documentation. Along with this some excessive DELAYs, which probably only were added because of bugs in gem_bitwait() and its use in the first place, as well as as have of an gem_bitwait() reimplementation in gem_reset_tx() were removed. o Add gem_reset_rxdma() and use it to deal with GEM_MAC_RX_OVERFLOW errors more gracefully as unlike gem_init_locked() it resets the RX DMA engine only, causing no link loss and the FIFOs not to be cleared. Also use it deal with GEM_INTR_RX_TAG_ERR errors, with previously were unhandled. This was based on information obtained from the Linux GEM and OpenSolaris ERI drivers. o Turn on workarounds for silicon bugs in the Apple GMAC variants. This was based on information obtained from the Darwin GMAC and Linux GEM drivers. o Turn on "infinite" (i.e. maximum 31 * 64 bytes in length) DMA bursts. This greatly improves especially RX performance. o Optimize the RX path, this consists of: - kicking the receiver as soon as we've a spare descriptor in gem_rint() again instead of just once after all the ready ones have been handled; - kicking the receiver the right way, i.e. as outlined in the GEM documentation in batches of 4 and by pointing it to the descriptor after the last valid one; - calling gem_rint() before gem_tint() in gem_intr() as gem_tint() may take quite a while; - doubling the size of the RX ring to 256 descriptors. Overall the RX performance of a GEM in a 1GHz Sun Fire V210 was improved from ~100Mbit/s to ~850Mbit/s. o In gem_add_rxbuf() don't assign the newly allocated mbuf to rxs_mbuf before calling bus_dmamap_load_mbuf_sg(), if bus_dmamap_load_mbuf_sg() fails we'll free the newly allocated mbuf, unable to recycle the previous one but a NULL pointer dereference instead. o In gem_init_locked() honor the return value of gem_meminit(). o Simplify gem_ringsize() and dont' return garbage in the default case. Based on OpenBSD. o Don't turn on MAC control, MIF and PCS interrupts unless GEM_DEBUG is defined as we don't need/use these interrupts for operation. o In gem_start_locked() sync the DMA maps of the descriptor rings before every kick of the transmitter and not just once after enqueuing all packets as the NIC might instantly start transmitting after we kicked it the first time. o Keep state of the link state and use it to enable or disable the MAC in gem_mii_statchg() accordingly as well as to return early from gem_start_locked() in case the link is down. [3] o Initialize the maximum frame size to a sane value. o In gem_mii_statchg() enable carrier extension if appropriate. o Increment if_ierrors in case of an GEM_MAC_RX_OVERFLOW error and in gem_eint(). [3] o Handle IFF_ALLMULTI correctly; don't set it if we've turned promiscuous group mode on and don't clear the flag if we've disabled promiscuous group mode (these were mostly NOPs though). [2] o Let gem_eint() also report GEM_INTR_PERR errors. o Move setting sc_variant from gem_pci_probe() to gem_pci_attach() as device probe methods are not supposed to touch the softc. o Collapse sc_inited and sc_pci into bits for sc_flags. o Add CTASSERTs ensuring that GEM_NRXDESC and GEM_NTXDESC are set to legal values. o Correctly set up for 802.3x flow control, though #ifdef out the code that actually enables it as this needs more testing and mainly a proper framework to support it. o Correct and add some conversions from hard-coded functions names to __func__ which were borked or forgotten in if_gem.c rev. 1.42. o Use PCIR_BAR instead of a homegrown macro. o Replace sc_enaddr[6] with sc_enaddr[ETHER_ADDR_LEN]. o In gem_pci_attach() in case attaching fails release the resources in the opposite order they were allocated. o Make gem_reset() static to if_gem.c as it's not needed outside that module. o Remove the GEM_GIGABIT flag and the associated code; GEM_GIGABIT was never set and the associated code was in the wrong place. o Remove sc_mif_config; it was only used to cache the contents of the respective register within gem_attach(). o Remove the #ifdef'ed out NetBSD/OpenBSD code for establishing a suspend hook as it will never be used on FreeBSD. o Also probe Apple Intrepid 2 GMAC and Apple Shasta GMAC, add support for Apple K2 GMAC. Based on OpenBSD. o Add support for Sun GBE/P cards, or in other words actually add support for cards based on GEM to gem(4). This mainly consists of adding support for the TBI of these chips. Along with this the PHY selection code was rewritten to hardcode the PHY number for certain configurations as for example the PHY of the on-board ERI of Blade 1000 shows up twice causing no link as the second incarnation is isolated. These changes were ported from OpenBSD with some additional improvements and modulo some bugs. o Add code to if_gem_pci.c allowing to read the MAC-address from the VPD on systems without Open Firmware. This is an improved version of my variant of the respective code in if_hme_pci.c o Now that gem(4) is MI enable it for all archs. Pointed out by: yongari [1] Suggested by: rwatson [2], yongari [3] Tested on: i386 (GEM), powerpc (GMACs by marcel and yongari), sparc64 (ERI and GEM) Reviewed by: yongari Approved by: re (kensmith)
2007-09-26 21:14:18 +00:00
device gem # Apple GMAC/Sun ERI/Sun GEM
device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet
device lge # Level 1 LXT1001 gigabit Ethernet
device lio # Support for Cavium 23XX Ethernet adapters
device mlxfw # Mellanox firmware update module
device mlx5 # Shared code module between IB and Ethernet
device mlx5en # Mellanox ConnectX-4 and ConnectX-4 LX
device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet
device my # Myson Fast Ethernet (MTD80X, MTD89X)
device nge # NatSemi DP83820 gigabit Ethernet
device re # RealTek 8139C+/8169/8169S/8110S
device rl # RealTek 8129/8139
device sge # Silicon Integrated Systems SiS190/191
device sis # Silicon Integrated Systems SiS 900/SiS 7016
device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet
device ste # Sundance ST201 (D-Link DFE-550TX)
device stge # Sundance/Tamarack TC9021 gigabit Ethernet
device vr # VIA Rhine, Rhine II
device vte # DM&P Vortex86 RDC R6040 Fast Ethernet
device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'')
# PCI/PCI-X/PCIe Ethernet NICs that use iflib infrastructure
device iflib
device em # Intel Pro/1000 Gigabit Ethernet
device ix # Intel Pro/10Gbe PCIE Ethernet
device ixv # Intel Pro/10Gbe PCIE Ethernet VF
# PCI Ethernet NICs.
device cxgb # Chelsio T3 10 Gigabit Ethernet
device cxgb_t3fw # Chelsio T3 10 Gigabit Ethernet firmware
device cxgbe # Chelsio T4-T6 1/10/25/40/100 Gigabit Ethernet
device cxgbev # Chelsio T4-T6 Virtual Functions
device le # AMD Am7900 LANCE and Am79C9xx PCnet
device mxge # Myricom Myri-10G 10GbE NIC
device oce # Emulex 10 GbE (OneConnect Ethernet)
device ti # Alteon Networks Tigon I/II gigabit Ethernet
# PCI IEEE 802.11 Wireless NICs
device ath # Atheros pci/cardbus NIC's
device ath_hal # pci/cardbus chip support
#device ath_ar5210 # AR5210 chips
#device ath_ar5211 # AR5211 chips
#device ath_ar5212 # AR5212 chips
#device ath_rf2413
#device ath_rf2417
#device ath_rf2425
#device ath_rf5111
#device ath_rf5112
#device ath_rf5413
#device ath_ar5416 # AR5416 chips
# All of the AR5212 parts have a problem when paired with the AR71xx
# CPUS. These parts have a bug that triggers a fatal bus error on the AR71xx
# only. Details of the exact nature of the bug are sketchy, but some can be
# found at https://forum.openwrt.org/viewtopic.php?pid=70060 on pages 4, 5 and
# 6. This option enables this workaround. There is a performance penalty
# for this work around, but without it things don't work at all. The DMA
# from the card usually bursts 128 bytes, but on the affected CPUs, only
# 4 are safe.
options AH_RXCFG_SDMAMW_4BYTES
#device ath_ar9160 # AR9160 chips
#device ath_ar9280 # AR9280 chips
#device ath_ar9285 # AR9285 chips
device ath_rate_sample # SampleRate tx rate control for ath
device bwi # Broadcom BCM430* BCM431*
2010-03-03 21:40:44 +00:00
device bwn # Broadcom BCM43xx
device malo # Marvell Libertas wireless NICs.
device mwl # Marvell 88W8363 802.11n wireless NICs.
device mwlfw
device ral # Ralink Technology RT2500 wireless NICs.
2016-05-27 03:30:42 +00:00
device rtwn # Realtek wireless NICs
device rtwnfw
# Use sf_buf(9) interface for jumbo buffers on ti(4) controllers.
#options TI_SF_BUF_JUMBO
At long last, commit the zero copy sockets code. MAKEDEV: Add MAKEDEV glue for the ti(4) device nodes. ti.4: Update the ti(4) man page to include information on the TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS kernel options, and also include information about the new character device interface and the associated ioctls. man9/Makefile: Add jumbo.9 and zero_copy.9 man pages and associated links. jumbo.9: New man page describing the jumbo buffer allocator interface and operation. zero_copy.9: New man page describing the general characteristics of the zero copy send and receive code, and what an application author should do to take advantage of the zero copy functionality. NOTES: Add entries for ZERO_COPY_SOCKETS, TI_PRIVATE_JUMBOS, TI_JUMBO_HDRSPLIT, MSIZE, and MCLSHIFT. conf/files: Add uipc_jumbo.c and uipc_cow.c. conf/options: Add the 5 options mentioned above. kern_subr.c: Receive side zero copy implementation. This takes "disposable" pages attached to an mbuf, gives them to a user process, and then recycles the user's page. This is only active when ZERO_COPY_SOCKETS is turned on and the kern.ipc.zero_copy.receive sysctl variable is set to 1. uipc_cow.c: Send side zero copy functions. Takes a page written by the user and maps it copy on write and assigns it kernel virtual address space. Removes copy on write mapping once the buffer has been freed by the network stack. uipc_jumbo.c: Jumbo disposable page allocator code. This allocates (optionally) disposable pages for network drivers that want to give the user the option of doing zero copy receive. uipc_socket.c: Add kern.ipc.zero_copy.{send,receive} sysctls that are enabled if ZERO_COPY_SOCKETS is turned on. Add zero copy send support to sosend() -- pages get mapped into the kernel instead of getting copied if they meet size and alignment restrictions. uipc_syscalls.c:Un-staticize some of the sf* functions so that they can be used elsewhere. (uipc_cow.c) if_media.c: In the SIOCGIFMEDIA ioctl in ifmedia_ioctl(), avoid calling malloc() with M_WAITOK. Return an error if the M_NOWAIT malloc fails. The ti(4) driver and the wi(4) driver, at least, call this with a mutex held. This causes witness warnings for 'ifconfig -a' with a wi(4) or ti(4) board in the system. (I've only verified for ti(4)). ip_output.c: Fragment large datagrams so that each segment contains a multiple of PAGE_SIZE amount of data plus headers. This allows the receiver to potentially do page flipping on receives. if_ti.c: Add zero copy receive support to the ti(4) driver. If TI_PRIVATE_JUMBOS is not defined, it now uses the jumbo(9) buffer allocator for jumbo receive buffers. Add a new character device interface for the ti(4) driver for the new debugging interface. This allows (a patched version of) gdb to talk to the Tigon board and debug the firmware. There are also a few additional debugging ioctls available through this interface. Add header splitting support to the ti(4) driver. Tweak some of the default interrupt coalescing parameters to more useful defaults. Add hooks for supporting transmit flow control, but leave it turned off with a comment describing why it is turned off. if_tireg.h: Change the firmware rev to 12.4.11, since we're really at 12.4.11 plus fixes from 12.4.13. Add defines needed for debugging. Remove the ti_stats structure, it is now defined in sys/tiio.h. ti_fw.h: 12.4.11 firmware. ti_fw2.h: 12.4.11 firmware, plus selected fixes from 12.4.13, and my header splitting patches. Revision 12.4.13 doesn't handle 10/100 negotiation properly. (This firmware is the same as what was in the tree previously, with the addition of header splitting support.) sys/jumbo.h: Jumbo buffer allocator interface. sys/mbuf.h: Add a new external mbuf type, EXT_DISPOSABLE, to indicate that the payload buffer can be thrown away / flipped to a userland process. socketvar.h: Add prototype for socow_setup. tiio.h: ioctl interface to the character portion of the ti(4) driver, plus associated structure/type definitions. uio.h: Change prototype for uiomoveco() so that we'll know whether the source page is disposable. ufs_readwrite.c:Update for new prototype of uiomoveco(). vm_fault.c: In vm_fault(), check to see whether we need to do a page based copy on write fault. vm_object.c: Add a new function, vm_object_allocate_wait(). This does the same thing that vm_object allocate does, except that it gives the caller the opportunity to specify whether it should wait on the uma_zalloc() of the object structre. This allows vm objects to be allocated while holding a mutex. (Without generating WITNESS warnings.) vm_object_allocate() is implemented as a call to vm_object_allocate_wait() with the malloc flag set to M_WAITOK. vm_object.h: Add prototype for vm_object_allocate_wait(). vm_page.c: Add page-based copy on write setup, clear and fault routines. vm_page.h: Add page based COW function prototypes and variable in the vm_page structure. Many thanks to Drew Gallatin, who wrote the zero copy send and receive code, and to all the other folks who have tested and reviewed this code over the years.
2002-06-26 03:37:47 +00:00
# Turn on the header splitting option for the ti(4) driver firmware. This
# only works for Tigon II chips, and has no effect for Tigon I chips.
# This option requires the TI_SF_BUF_JUMBO option above.
#options TI_JUMBO_HDRSPLIT
At long last, commit the zero copy sockets code. MAKEDEV: Add MAKEDEV glue for the ti(4) device nodes. ti.4: Update the ti(4) man page to include information on the TI_JUMBO_HDRSPLIT and TI_PRIVATE_JUMBOS kernel options, and also include information about the new character device interface and the associated ioctls. man9/Makefile: Add jumbo.9 and zero_copy.9 man pages and associated links. jumbo.9: New man page describing the jumbo buffer allocator interface and operation. zero_copy.9: New man page describing the general characteristics of the zero copy send and receive code, and what an application author should do to take advantage of the zero copy functionality. NOTES: Add entries for ZERO_COPY_SOCKETS, TI_PRIVATE_JUMBOS, TI_JUMBO_HDRSPLIT, MSIZE, and MCLSHIFT. conf/files: Add uipc_jumbo.c and uipc_cow.c. conf/options: Add the 5 options mentioned above. kern_subr.c: Receive side zero copy implementation. This takes "disposable" pages attached to an mbuf, gives them to a user process, and then recycles the user's page. This is only active when ZERO_COPY_SOCKETS is turned on and the kern.ipc.zero_copy.receive sysctl variable is set to 1. uipc_cow.c: Send side zero copy functions. Takes a page written by the user and maps it copy on write and assigns it kernel virtual address space. Removes copy on write mapping once the buffer has been freed by the network stack. uipc_jumbo.c: Jumbo disposable page allocator code. This allocates (optionally) disposable pages for network drivers that want to give the user the option of doing zero copy receive. uipc_socket.c: Add kern.ipc.zero_copy.{send,receive} sysctls that are enabled if ZERO_COPY_SOCKETS is turned on. Add zero copy send support to sosend() -- pages get mapped into the kernel instead of getting copied if they meet size and alignment restrictions. uipc_syscalls.c:Un-staticize some of the sf* functions so that they can be used elsewhere. (uipc_cow.c) if_media.c: In the SIOCGIFMEDIA ioctl in ifmedia_ioctl(), avoid calling malloc() with M_WAITOK. Return an error if the M_NOWAIT malloc fails. The ti(4) driver and the wi(4) driver, at least, call this with a mutex held. This causes witness warnings for 'ifconfig -a' with a wi(4) or ti(4) board in the system. (I've only verified for ti(4)). ip_output.c: Fragment large datagrams so that each segment contains a multiple of PAGE_SIZE amount of data plus headers. This allows the receiver to potentially do page flipping on receives. if_ti.c: Add zero copy receive support to the ti(4) driver. If TI_PRIVATE_JUMBOS is not defined, it now uses the jumbo(9) buffer allocator for jumbo receive buffers. Add a new character device interface for the ti(4) driver for the new debugging interface. This allows (a patched version of) gdb to talk to the Tigon board and debug the firmware. There are also a few additional debugging ioctls available through this interface. Add header splitting support to the ti(4) driver. Tweak some of the default interrupt coalescing parameters to more useful defaults. Add hooks for supporting transmit flow control, but leave it turned off with a comment describing why it is turned off. if_tireg.h: Change the firmware rev to 12.4.11, since we're really at 12.4.11 plus fixes from 12.4.13. Add defines needed for debugging. Remove the ti_stats structure, it is now defined in sys/tiio.h. ti_fw.h: 12.4.11 firmware. ti_fw2.h: 12.4.11 firmware, plus selected fixes from 12.4.13, and my header splitting patches. Revision 12.4.13 doesn't handle 10/100 negotiation properly. (This firmware is the same as what was in the tree previously, with the addition of header splitting support.) sys/jumbo.h: Jumbo buffer allocator interface. sys/mbuf.h: Add a new external mbuf type, EXT_DISPOSABLE, to indicate that the payload buffer can be thrown away / flipped to a userland process. socketvar.h: Add prototype for socow_setup. tiio.h: ioctl interface to the character portion of the ti(4) driver, plus associated structure/type definitions. uio.h: Change prototype for uiomoveco() so that we'll know whether the source page is disposable. ufs_readwrite.c:Update for new prototype of uiomoveco(). vm_fault.c: In vm_fault(), check to see whether we need to do a page based copy on write fault. vm_object.c: Add a new function, vm_object_allocate_wait(). This does the same thing that vm_object allocate does, except that it gives the caller the opportunity to specify whether it should wait on the uma_zalloc() of the object structre. This allows vm objects to be allocated while holding a mutex. (Without generating WITNESS warnings.) vm_object_allocate() is implemented as a call to vm_object_allocate_wait() with the malloc flag set to M_WAITOK. vm_object.h: Add prototype for vm_object_allocate_wait(). vm_page.c: Add page-based copy on write setup, clear and fault routines. vm_page.h: Add page based COW function prototypes and variable in the vm_page structure. Many thanks to Drew Gallatin, who wrote the zero copy send and receive code, and to all the other folks who have tested and reviewed this code over the years.
2002-06-26 03:37:47 +00:00
# These two options allow manipulating the mbuf cluster size and mbuf size,
# respectively. Be very careful with NIC driver modules when changing
# these from their default values, because that can potentially cause a
# mismatch between the mbuf size assumed by the kernel and the mbuf size
# assumed by a module. The only driver that currently has the ability to
# detect a mismatch is ti(4).
options MCLSHIFT=11 # mbuf cluster shift in bits, 11 == 2KB
options MSIZE=256 # mbuf size in bytes
#
# Sound drivers
#
# sound: The generic sound driver.
#
device sound
#
# snd_*: Device-specific drivers.
#
# The flags of the device tell the device a bit more info about the
# device that normally is obtained through the PnP interface.
# bit 2..0 secondary DMA channel;
# bit 4 set if the board uses two dma channels;
# bit 15..8 board type, overrides autodetection; leave it
# zero if don't know what to put in (and you don't,
# since this is unsupported at the moment...).
#
# snd_als4000: Avance Logic ALS4000 PCI.
# snd_atiixp: ATI IXP 200/300/400 PCI.
# snd_cmi: CMedia CMI8338/CMI8738 PCI.
# snd_cs4281: Crystal Semiconductor CS4281 PCI.
# snd_csa: Crystal Semiconductor CS461x/428x PCI. (except
# 4281)
# snd_emu10k1: Creative EMU10K1 PCI and EMU10K2 (Audigy) PCI.
# snd_emu10kx: Creative SoundBlaster Live! and Audigy
2006-09-30 17:59:08 +00:00
# snd_envy24: VIA Envy24 and compatible, needs snd_spicds.
# snd_envy24ht: VIA Envy24HT and compatible, needs snd_spicds.
# snd_es137x: Ensoniq AudioPCI ES137x PCI.
# snd_fm801: Forte Media FM801 PCI.
# snd_hda: Intel High Definition Audio (Controller) and
# compatible.
# snd_hdspe: RME HDSPe AIO and RayDAT.
# snd_ich: Intel ICH AC'97 and some more audio controllers
# embedded in a chipset, for example nVidia
# nForce controllers.
# snd_maestro3: ESS Technology Maestro-3/Allegro PCI.
# snd_neomagic: Neomagic 256 AV/ZX PCI.
# snd_solo: ESS Solo-1x PCI.
2011-07-15 19:02:44 +00:00
# snd_spicds: SPI codec driver, needed by Envy24/Envy24HT drivers.
# snd_t4dwave: Trident 4DWave DX/NX PCI, Sis 7018 PCI and Acer Labs
# M5451 PCI.
2011-07-15 19:02:44 +00:00
# snd_uaudio: USB audio.
# snd_via8233: VIA VT8233x PCI.
# snd_via82c686: VIA VT82C686A PCI.
# snd_vibes: S3 Sonicvibes PCI.
device snd_als4000
device snd_atiixp
device snd_cmi
device snd_cs4281
device snd_csa
device snd_emu10k1
device snd_emu10kx
device snd_envy24
2006-09-30 17:59:08 +00:00
device snd_envy24ht
device snd_es137x
device snd_fm801
device snd_hda
device snd_hdspe
device snd_ich
device snd_maestro3
device snd_neomagic
device snd_solo
2006-09-30 17:59:08 +00:00
device snd_spicds
device snd_t4dwave
2011-07-15 19:02:44 +00:00
device snd_uaudio
device snd_via8233
device snd_via82c686
device snd_vibes
2006-08-24 08:00:02 +00:00
# For non-PnP sound cards:
envvar hint.pcm.0.at="isa"
envvar hint.pcm.0.irq="10"
envvar hint.pcm.0.drq="1"
envvar hint.pcm.0.flags="0x0"
envvar hint.sbc.0.at="isa"
envvar hint.sbc.0.port="0x220"
envvar hint.sbc.0.irq="5"
envvar hint.sbc.0.drq="1"
envvar hint.sbc.0.flags="0x15"
envvar hint.gusc.0.at="isa"
envvar hint.gusc.0.port="0x220"
envvar hint.gusc.0.irq="5"
envvar hint.gusc.0.drq="1"
envvar hint.gusc.0.flags="0x13"
2009-06-08 04:39:47 +00:00
#
# Following options are intended for debugging/testing purposes:
#
# SND_DEBUG Enable extra debugging code that includes
# sanity checking and possible increase of
# verbosity.
#
# SND_DIAGNOSTIC Similar in a spirit of INVARIANTS/DIAGNOSTIC,
2009-06-08 04:39:47 +00:00
# zero tolerance against inconsistencies.
#
# SND_FEEDER_MULTIFORMAT By default, only 16/32 bit feeders are compiled
# in. This options enable most feeder converters
# except for 8bit. WARNING: May bloat the kernel.
#
# SND_FEEDER_FULL_MULTIFORMAT Ditto, but includes 8bit feeders as well.
#
# SND_FEEDER_RATE_HP (feeder_rate) High precision 64bit arithmetic
# as much as possible (the default trying to
# avoid it). Possible slowdown.
#
# SND_PCM_64 (Only applicable for i386/32bit arch)
# Process 32bit samples through 64bit
# integer/arithmetic. Slight increase of dynamic
# range at a cost of possible slowdown.
#
# SND_OLDSTEREO Only 2 channels are allowed, effectively
# disabling multichannel processing.
#
options SND_DEBUG
options SND_DIAGNOSTIC
options SND_FEEDER_MULTIFORMAT
options SND_FEEDER_FULL_MULTIFORMAT
options SND_FEEDER_RATE_HP
options SND_PCM_64
options SND_OLDSTEREO
2009-06-08 04:39:47 +00:00
#
# Cardbus
#
# cbb: pci/CardBus bridge implementing YENTA interface
# cardbus: CardBus slots
device cbb
device cardbus
#
# MMC/SD
#
# mmc MMC/SD bus
# mmcsd MMC/SD memory card
# sdhci Generic PCI SD Host Controller
# rtsx Realtek SD card reader (RTS5209, RTS5227, ...)
device mmc
device mmcsd
device sdhci
device rtsx
#
# SMB bus
#
# System Management Bus support is provided by the 'smbus' device.
# Access to the SMBus device is via the 'smb' device (/dev/smb*),
# which is a child of the 'smbus' device.
#
# Supported devices:
# smb standard I/O through /dev/smb*
#
# Supported SMB interfaces:
# iicsmb I2C to SMB bridge with any iicbus interface
# intpm Intel PIIX4 (82371AB, 82443MX) Power Management Unit
# alpm Acer Aladdin-IV/V/Pro2 Power Management Unit
# ichsmb Intel ICH SMBus controller chips (82801AA, 82801AB, 82801BA)
2004-01-25 12:32:56 +00:00
# viapm VIA VT82C586B/596B/686A and VT8233 Power Management Unit
# amdpm AMD 756 Power Management Unit
# amdsmb AMD 8111 SMBus 2.0 Controller
# nfpm NVIDIA nForce Power Management Unit
# nfsmb NVIDIA nForce2/3/4 MCP SMBus 2.0 Controller
# ismt Intel SMBus 2.0 controller chips (on Atom S1200, C2000)
#
device smbus # Bus support, required for smb below.
device intpm
device alpm
device ichsmb
device viapm
device amdpm
device amdsmb
device nfpm
device nfsmb
device ismt
device smb
# SMBus peripheral devices
#
# jedec_dimm Asset and temperature reporting for DDR3 and DDR4 DIMMs
#
device jedec_dimm
# I2C Bus
#
# Philips i2c bus support is provided by the `iicbus' device.
#
# Supported devices:
# ic i2c network interface
# iic i2c standard io
# iicsmb i2c to smb bridge. Allow i2c i/o with smb commands.
# iicoc simple polling driver for OpenCores I2C controller
#
# Other:
# iicbb generic I2C bit-banging code (needed by lpbb)
#
device iicbus # Bus support, required for ic/iic/iicsmb below.
device iicbb # bitbang driver; implements i2c on a pair of gpio pins
device ic
device iic # userland access to i2c slave devices via ioctl(8)
device iicsmb # smb over i2c bridge
device iicoc # OpenCores I2C controller support
Add support for i2c bus mux hardware. An i2c bus can be divided into segments which can be selectively connected and disconnected from the main bus. This is usually done to enable using multiple slave devices having the same address, by isolating the devices onto separate bus segments, only one of which is connected to the main bus at once. There are several types of i2c bus muxes, which break down into two general categories... - Muxes which are themselves i2c slaves. These devices respond to i2c commands on their upstream bus, and based on those commands, connect various downstream buses to the upstream. In newbus terms, they are both a child of an iicbus and the parent of one or more iicbus instances. - Muxes which are not i2c devices themselves. Such devices are part of the i2c bus electrically, but in newbus terms their parent is some other bus. The association with the upstream bus must be established by separate metadata (such as FDT data). In both cases, the mux driver has one or more iicbus child instances representing the downstream buses. The mux driver implements the iicbus_if interface, as if it were an iichb host bridge/i2c controller driver. It services the IO requests sent to it by forwarding them to the iicbus instance representing the upstream bus, after electrically connecting the upstream bus to the downstream bus that hosts the i2c slave device which made the IO request. The net effect is automatic mux switching which is transparent to slaves on the downstream buses. They just do i2c IO they way they normally do, and the bus is electrically connected for the duration of the IO and then idled when it is complete. The existing iicbus_if callback() method is enhanced so that the parameter passed to it can be a struct which contains a device_t for the requesting bus and slave devices. This change is done by adding a flag that indicates the extra values are present, and making the flags field the first field of a new args struct. If the flag is set, the iichb or mux driver can recast the pointer-to-flags into a pointer-to-struct and access the extra fields. Thus abi compatibility with older drivers is retained (but a mux cannot exist on the bus with the older iicbus driver in use.) A new set of core support routines exists in iicbus.c. This code will help implement mux drivers for any type of mux hardware by supplying all the boilerplate code that forwards IO requests upstream. It also has code for parsing metadata and instantiating the child iicbus instances based on it. Two new hardware mux drivers are added. The ltc430x driver supports the LTC4305/4306 mux chips which are controlled via i2c commands. The iic_gpiomux driver supports any mux hardware which is controlled by manipulating the state of one or more gpio pins. Test Plan Tested locally using a variety of mux'd bus configurations involving both ltc4305 and a homebrew gpio-controlled mux. Tested configurations included cascaded muxes (unlikely in the real world, but useful to prove that 'it all just works' in terms of the automatic switching and upstream forwarding of IO requests).
2020-01-02 17:51:49 +00:00
# I2C bus multiplexer (mux) devices
device iicmux # i2c mux core driver
device iic_gpiomux # i2c mux hardware controlled via gpio pins
device ltc430x # LTC4305 and LTC4306 i2c mux chips
# I2C peripheral devices
#
device ad7418 # Analog Devices temp and voltage sensor
device ads111x # Texas Instruments ADS101x and ADS111x ADCs
device ds1307 # Dallas DS1307 RTC and compatible
device ds13rtc # All Dallas/Maxim ds13xx chips
device ds1672 # Dallas DS1672 RTC
device ds3231 # Dallas DS3231 RTC + temperature
device fan53555 # Fairchild Semi FAN53555/SYR82x Regulator
device icee # AT24Cxxx and compatible EEPROMs
device isl12xx # Intersil ISL12xx RTC
device lm75 # LM75 compatible temperature sensor
device nxprtc # NXP RTCs: PCA/PFC212x PCA/PCF85xx
device rtc8583 # Epson RTC-8583
device s35390a # Seiko Instruments S-35390A RTC
device sy8106a # Silergy Corp. SY8106A buck regulator
# Parallel-Port Bus
#
# Parallel port bus support is provided by the `ppbus' device.
# Multiple devices may be attached to the parallel port, devices
# are automatically probed and attached when found.
#
# Supported devices:
# lpt Parallel Printer
# plip Parallel network interface
# ppi General-purpose I/O ("Geek Port") + IEEE1284 I/O
# pps Pulse per second Timing Interface
# lpbb Philips official parallel port I2C bit-banging interface
2009-02-08 12:12:19 +00:00
# pcfclock Parallel port clock driver.
#
# Supported interfaces:
# ppc ISA-bus parallel port interfaces.
#
1999-01-23 17:06:01 +00:00
options PPC_PROBE_CHIPSET # Enable chipset specific detection
# (see flags in ppc(4))
options DEBUG_1284 # IEEE1284 signaling protocol debug
options PERIPH_1284 # Makes your computer act as an IEEE1284
1999-01-23 17:06:01 +00:00
# compliant peripheral
options DONTPROBE_1284 # Avoid boot detection of PnP parallel devices
options LPT_DEBUG # Printer driver debug
options PPC_DEBUG # Parallel chipset level debug
options PLIP_DEBUG # Parallel network IP interface debug
options PCFCLOCK_VERBOSE # Verbose pcfclock driver
options PCFCLOCK_MAX_RETRIES=5 # Maximum read tries (default 10)
1999-01-23 17:06:01 +00:00
Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others
2000-06-13 22:28:50 +00:00
device ppc
envvar hint.ppc.0.at="isa"
envvar hint.ppc.0.irq="7"
device ppbus
device lpt
device plip
device ppi
device pps
device lpbb
device pcfclock
# General Purpose I/O pins
device dwgpio # Synopsys DesignWare APB GPIO Controller
device gpio # gpio interfaces and bus support
device gpiobacklight # sysctl control of gpio-based backlight
device gpioiic # i2c via gpio bitbang
device gpiokeys # kbd(4) glue for gpio-based key input
device gpioled # led(4) gpio glue
device gpiopower # event handler for gpio-based powerdown
device gpiopps # Pulse per second input from gpio pin
device gpioregulator # extres/regulator glue for gpio pin
device gpiospi # SPI via gpio bitbang
device gpioths # 1-wire temp/humidity sensor on gpio pin
2019-06-24 02:39:56 +00:00
# Pulse width modulation
device pwmbus # pwm interface and bus support
device pwmc # userland control access to pwm outputs
#
# Etherswitch framework and drivers
#
# etherswitch The etherswitch(4) framework
# miiproxy Proxy device for miibus(4) functionality
#
# Switch hardware support:
# arswitch Atheros switches
# ip17x IC+ 17x family switches
# rtl8366r Realtek RTL8366 switches
# ukswitch Multi-PHY switches
#
device etherswitch
device miiproxy
device arswitch
device ip17x
device rtl8366rb
device ukswitch
# Kernel BOOTP support
options BOOTP # Use BOOTP to obtain IP address/hostname
# Requires NFSCL and NFS_ROOT
options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info
options BOOTP_NFSV3 # Use NFS v3 to NFS mount root
options BOOTP_COMPAT # Workaround for broken bootp daemons.
options BOOTP_WIRED_TO=fxp0 # Use interface fxp0 for BOOTP
options BOOTP_BLOCKSIZE=8192 # Override NFS block size
#
# Enable software watchdog routines, even if hardware watchdog is present.
# By default, software watchdog timer is enabled only if no hardware watchdog
# is present.
#
options SW_WATCHDOG
#
# Add the software deadlock resolver thread.
#
options DEADLKRES
#
# Disable swapping of stack pages. This option removes all
2003-04-11 14:48:13 +00:00
# code which actually performs swapping, so it's not possible to turn
# it back on at run-time.
#
# This is sometimes usable for systems which don't have any swap space
# (see also sysctl "vm.disable_swapspace_pageouts")
#
#options NO_SWAPPING
1998-11-05 14:36:37 +00:00
# Set the number of sf_bufs to allocate. sf_bufs are virtual buffers
# for sendfile(2) that are used to map file VM pages, and normally
# default to a quantity that is roughly 16*MAXUSERS+512. You would
# typically want about 4 of these for each simultaneous file send.
#
options NSFBUFS=1024
1998-11-05 14:36:37 +00:00
#
# Enable extra debugging code for locks. This stores the filename and
# line of whatever acquired the lock in the lock itself, and changes a
# number of function calls to pass around the relevant data. This is
# not at all useful unless you are debugging lock code. Note that
# modules should be recompiled as this option modifies KBI.
#
options DEBUG_LOCKS
#####################################################################
# HID support
device hid # Generic HID support
options HID_DEBUG # enable debug msgs
device hidbus # HID bus
device hidmap # HID to evdev mapping
device hidraw # Raw access driver
options HIDRAW_MAKE_UHID_ALIAS # install /dev/uhid alias
device hconf # Multitouch configuration TLC
device hcons # Consumer controls
device hgame # Generic game controllers
device hkbd # HID keyboard
device hms # HID mouse
device hmt # HID multitouch (MS-compatible)
device hpen # Generic pen driver
device hsctrl # System controls
device ps4dshock # Sony PS4 DualShock 4 gamepad driver
device xb360gp # XBox 360 gamepad driver
#####################################################################
# USB support
# UHCI controller
device uhci
# OHCI controller
device ohci
# EHCI controller
device ehci
# XHCI controller
device xhci
# SL811 Controller
#device slhci
# General USB code (mandatory for USB)
device usb
#
# USB Double Bulk Pipe devices
device udbp
# USB temperature meter
device ugold
# USB LED
device uled
# Human Interface Device (anything with buttons and dials)
device uhid
# USB keyboard
device ukbd
# USB printer
device ulpt
# USB mass storage driver (Requires scbus and da)
device umass
# USB mass storage driver for device-side mode
device usfs
2003-06-28 05:47:34 +00:00
# USB support for Belkin F5U109 and Magic Control Technology serial adapters
device umct
2000-07-18 10:49:45 +00:00
# USB modem support
device umodem
# USB mouse
device ums
# USB touchpad(s)
device atp
device wsp
# eGalax USB touch screen
device uep
2006-08-24 08:00:02 +00:00
# Diamond Rio 500 MP3 player
device urio
# HID-over-USB driver
device usbhid
#
# USB serial support
device ucom
2008-10-24 07:16:13 +00:00
# USB support for 3G modem cards by Option, Novatel, Huawei and Sierra
device u3g
# USB support for Technologies ARK3116 based serial adapters
device uark
# USB support for Belkin F5U103 and compatible serial adapters
device ubsa
# USB support for serial adapters based on the FT8U100AX and FT8U232AM
device uftdi
# USB support for some Windows CE based serial communication.
device uipaq
# USB support for Prolific PL-2303 serial adapters
device uplcom
# USB support for Silicon Laboratories CP2101/CP2102 based USB serial adapters
device uslcom
# USB Visor and Palm devices
device uvisor
# USB serial support for DDI pocket's PHS
device uvscom
#
# USB ethernet support
device uether
This commit adds device driver support for the ADMtek AN986 Pegasus USB ethernet chip. Adapters that use this chip include the LinkSys USB100TX. There are a few others, but I'm not certain of their availability in the U.S. I used an ADMtek eval board for development. Note that while the ADMtek chip is a 100Mbps device, you can't really get 100Mbps speeds over USB. Regardless, this driver uses miibus to allow speed and duplex mode selection as well as autonegotiation. Building and kldloading the driver as a module is also supported. Note that in order to make this driver work, I had to make what some may consider an ugly hack to sys/dev/usb/usbdi.c. The usbd_transfer() function will use tsleep() for synchronous transfers that don't complete right away. This is a problem since there are times when we need to do sync transfers from an interrupt context (i.e. when reading registers from the MAC via the control endpoint), where tsleep() us a no-no. My hack allows the driver to have the code poll for transfer completion subject to the xfer->timeout timeout rather that calling tsleep(). This hack is controlled by a quirk entry and is only enabled for the ADMtek device. Now, I'm sure there are a few of you out there ready to jump on me and suggest some other approach that doesn't involve a busy wait. The only solution that might work is to handle the interrupts in a kernel thread, where you may have something resembling a process context that makes it okay to tsleep(). This is lovely, except we don't have any mechanism like that now, and I'm not about to implement such a thing myself since it's beyond the scope of driver development. (Translation: I'll be damned if I know how to do it.) If FreeBSD ever aquires such a mechanism, I'll be glad to revisit the driver to take advantage of it. In the meantime, I settled for what I perceived to be the solution that involved the least amount of code changes. In general, the hit is pretty light. Also note that my only USB test box has a UHCI controller: I haven't I don't have a machine with an OHCI controller available. Highlights: - Updated usb_quirks.* to add UQ_NO_TSLEEP quirk for ADMtek part. - Updated usbdevs and regenerated generated files - Updated HARDWARE.TXT and RELNOTES.TXT files - Updated sysinstall/device.c and userconfig.c - Updated kernel configs -- device aue0 is commented out by default - Updated /sys/conf/files - Added new kld module directory
1999-12-28 02:01:18 +00:00
# ADMtek USB ethernet. Supports the LinkSys USB100TX,
# the Billionton USB100, the Melco LU-ATX, the D-Link DSB-650TX
# and the SMC 2202USB. Also works with the ADMtek AN986 Pegasus
# eval board.
device aue
# ASIX Electronics AX88172 USB 2.0 ethernet driver. Used in the
# LinkSys USB200M and various other adapters.
device axe
2014-05-17 18:40:43 +00:00
# ASIX Electronics AX88178A/AX88179 USB 2.0/3.0 gigabit ethernet driver.
device axge
#
# Devices which communicate using Ethernet over USB, particularly
# Communication Device Class (CDC) Ethernet specification. Supports
# Sharp Zaurus PDAs, some DOCSIS cable modems and so on.
device cdce
#
# CATC USB-EL1201A USB ethernet. Supports the CATC Netmate
# and Netmate II, and the Belkin F5U111.
device cue
#
# Kawasaki LSI ethernet. Supports the LinkSys USB10T,
# Entrega USB-NET-E45, Peracom Ethernet Adapter, the
# 3Com 3c19250, the ADS Technologies USB-10BT, the ATen UC10T,
# the Netgear EA101, the D-Link DSB-650, the SMC 2102USB
# and 2104USB, and the Corega USB-T.
device kue
#
# RealTek RTL8150 USB to fast ethernet. Supports the Melco LUA-KTX
# and the GREEN HOUSE GH-USB100B.
device rue
#
# Davicom DM9601E USB to fast ethernet. Supports the Corega FEther USB-TXC.
device udav
#
# RealTek RTL8152/RTL8153 USB Ethernet driver
device ure
#
2011-04-01 03:41:41 +00:00
# Moschip MCS7730/MCS7840 USB to fast ethernet. Supports the Sitecom LN030.
device mos
#
# HSxPA devices from Option N.V
device uhso
# Realtek RTL8188SU/RTL8191SU/RTL8192SU wireless driver
device rsu
#
2009-05-01 17:17:06 +00:00
# Ralink Technology RT2501USB/RT2601USB wireless driver
device rum
2010-01-28 22:28:59 +00:00
# Ralink Technology RT2700U/RT2800U/RT3000U wireless driver
device run
2009-05-01 17:17:06 +00:00
#
# Atheros AR5523 wireless driver
device uath
#
# Conexant/Intersil PrismGT wireless driver
device upgt
#
2009-05-01 17:17:06 +00:00
# Ralink Technology RT2500USB wireless driver
device ural
#
# RNDIS USB ethernet driver
device urndis
2011-04-29 06:36:39 +00:00
# Realtek RTL8187B/L wireless driver
device urtw
#
2009-05-01 17:17:06 +00:00
# ZyDas ZD1211/ZD1211B wireless driver
device zyd
2013-04-26 13:03:22 +00:00
#
# Sierra USB wireless driver
device usie
#
# debugging options for the USB subsystem
#
options USB_DEBUG
options U3G_DEBUG
The second phase of syscons reorganization. - Split syscons source code into manageable chunks and reorganize some of complicated functions. - Many static variables are moved to the softc structure. - Added a new key function, PREV. When this key is pressed, the vty immediately before the current vty will become foreground. Analogue to PREV, which is usually assigned to the PrntScrn key. PR: kern/10113 Submitted by: Christian Weisgerber <naddy@mips.rhein-neckar.de> - Modified the kernel console input function sccngetc() so that it handles function keys properly. - Reorganized the screen update routine. - VT switching code is reorganized. It now should be slightly more robust than before. - Added the DEVICE_RESUME function so that syscons no longer hooks the APM resume event directly. - New kernel configuration options: SC_NO_CUTPASTE, SC_NO_FONT_LOADING, SC_NO_HISTORY and SC_NO_SYSMOUSE. Various parts of syscons can be omitted so that the kernel size is reduced. SC_PIXEL_MODE Made the VESA 800x600 mode an option, rather than a standard part of syscons. SC_DISABLE_DDBKEY Disables the `debug' key combination. SC_ALT_MOUSE_IMAGE Inverse the character cell at the mouse cursor position in the text console, rather than drawing an arrow on the screen. Submitted by: Nick Hibma (n_hibma@FreeBSD.ORG) SC_DFLT_FONT makeoptions "SC_DFLT_FONT=_font_name_" Include the named font as the default font of syscons. 16-line, 14-line and 8-line font data will be compiled in. This option replaces the existing STD8X16FONT option, which loads 16-line font data only. - The VGA driver is split into /sys/dev/fb/vga.c and /sys/isa/vga_isa.c. - The video driver provides a set of ioctl commands to manipulate the frame buffer. - New kernel configuration option: VGA_WIDTH90 Enables 90 column modes: 90x25, 90x30, 90x43, 90x50, 90x60. These modes are mot always supported by the video card. PR: i386/7510 Submitted by: kbyanc@freedomnet.com and alexv@sui.gda.itesm.mx. - The header file machine/console.h is reorganized; its contents is now split into sys/fbio.h, sys/kbio.h (a new file) and sys/consio.h (another new file). machine/console.h is still maintained for compatibility reasons. - Kernel console selection/installation routines are fixed and slightly rebumped so that it should now be possible to switch between the interanl kernel console (sc or vt) and a remote kernel console (sio) again, as it was in 2.x, 3.0 and 3.1. - Screen savers and splash screen decoders Because of the header file reorganization described above, screen savers and splash screen decoders are slightly modified. After this update, /sys/modules/syscons/saver.h is no longer necessary and is removed.
1999-06-22 14:14:06 +00:00
# options for ukbd:
options UKBD_DFLT_KEYMAP # specify the built-in keymap
makeoptions UKBD_DFLT_KEYMAP=jp.106
The second phase of syscons reorganization. - Split syscons source code into manageable chunks and reorganize some of complicated functions. - Many static variables are moved to the softc structure. - Added a new key function, PREV. When this key is pressed, the vty immediately before the current vty will become foreground. Analogue to PREV, which is usually assigned to the PrntScrn key. PR: kern/10113 Submitted by: Christian Weisgerber <naddy@mips.rhein-neckar.de> - Modified the kernel console input function sccngetc() so that it handles function keys properly. - Reorganized the screen update routine. - VT switching code is reorganized. It now should be slightly more robust than before. - Added the DEVICE_RESUME function so that syscons no longer hooks the APM resume event directly. - New kernel configuration options: SC_NO_CUTPASTE, SC_NO_FONT_LOADING, SC_NO_HISTORY and SC_NO_SYSMOUSE. Various parts of syscons can be omitted so that the kernel size is reduced. SC_PIXEL_MODE Made the VESA 800x600 mode an option, rather than a standard part of syscons. SC_DISABLE_DDBKEY Disables the `debug' key combination. SC_ALT_MOUSE_IMAGE Inverse the character cell at the mouse cursor position in the text console, rather than drawing an arrow on the screen. Submitted by: Nick Hibma (n_hibma@FreeBSD.ORG) SC_DFLT_FONT makeoptions "SC_DFLT_FONT=_font_name_" Include the named font as the default font of syscons. 16-line, 14-line and 8-line font data will be compiled in. This option replaces the existing STD8X16FONT option, which loads 16-line font data only. - The VGA driver is split into /sys/dev/fb/vga.c and /sys/isa/vga_isa.c. - The video driver provides a set of ioctl commands to manipulate the frame buffer. - New kernel configuration option: VGA_WIDTH90 Enables 90 column modes: 90x25, 90x30, 90x43, 90x50, 90x60. These modes are mot always supported by the video card. PR: i386/7510 Submitted by: kbyanc@freedomnet.com and alexv@sui.gda.itesm.mx. - The header file machine/console.h is reorganized; its contents is now split into sys/fbio.h, sys/kbio.h (a new file) and sys/consio.h (another new file). machine/console.h is still maintained for compatibility reasons. - Kernel console selection/installation routines are fixed and slightly rebumped so that it should now be possible to switch between the interanl kernel console (sc or vt) and a remote kernel console (sio) again, as it was in 2.x, 3.0 and 3.1. - Screen savers and splash screen decoders Because of the header file reorganization described above, screen savers and splash screen decoders are slightly modified. After this update, /sys/modules/syscons/saver.h is no longer necessary and is removed.
1999-06-22 14:14:06 +00:00
# options for uplcom:
2004-06-26 17:19:44 +00:00
options UPLCOM_INTR_INTERVAL=100 # interrupt pipe interval
# in milliseconds
# options for uvscom:
options UVSCOM_DEFAULT_OPKTSIZE=8 # default output packet size
2004-06-26 17:19:44 +00:00
options UVSCOM_INTR_INTERVAL=100 # interrupt pipe interval
# in milliseconds
2002-11-07 16:19:43 +00:00
#####################################################################
# FireWire support
2002-11-07 16:19:43 +00:00
device firewire # FireWire bus code
2002-11-07 16:19:43 +00:00
device sbp # SCSI over Firewire (Requires scbus and da)
2003-11-14 11:54:49 +00:00
device sbp_targ # SBP-2 Target mode (Requires scbus and targ)
device fwe # Ethernet over FireWire (non-standard!)
2006-08-24 08:00:02 +00:00
device fwip # IP over FireWire (RFC2734 and RFC3146)
#####################################################################
# dcons support (Dumb Console Device)
device dcons # dumb console driver
device dcons_crom # FireWire attachment
options DCONS_BUF_SIZE=16384 # buffer size
options DCONS_POLL_HZ=100 # polling rate
options DCONS_FORCE_CONSOLE=0 # force to be the primary console
options DCONS_FORCE_GDB=1 # force to be the gdb device
2002-11-07 16:19:43 +00:00
#####################################################################
# crypto subsystem
#
2006-08-24 08:00:02 +00:00
# This is a port of the OpenBSD crypto framework. Include this when
# configuring IPSEC and when you have a h/w crypto device to accelerate
2006-08-24 08:00:02 +00:00
# user applications that link to OpenSSL.
#
2006-08-24 08:00:02 +00:00
# Drivers are ports from OpenBSD with some simple enhancements that have
# been fed back to OpenBSD.
device crypto # core crypto support
# Only install the cryptodev device if you are running tests, or know
2015-07-14 06:34:57 +00:00
# specifically why you need it. In most cases, it is not needed and
# will make things slower.
device cryptodev # /dev/crypto for access to h/w
device rndtest # FIPS 140-2 entropy tester
device ccr # Chelsio T6
device hifn # Hifn 7951, 7781, etc.
options HIFN_DEBUG # enable debugging support: hw.hifn.debug
options HIFN_RNDTEST # enable rndtest support
#####################################################################
#
# Embedded system options:
#
# An embedded system might want to run something other than init.
options INIT_PATH=/sbin/init:/rescue/init
# Debug options
options BUS_DEBUG # enable newbus debugging
2006-08-24 08:00:02 +00:00
options DEBUG_VFS_LOCKS # enable VFS lock debugging
options SOCKBUF_DEBUG # enable sockbuf last record/mb tail checking
options IFMEDIA_DEBUG # enable debugging in net/if_media.c
#
# Verbose SYSINIT
#
# Make the SYSINIT process performed by mi_startup() verbose. This is very
# useful when porting to a new architecture. If DDB is also enabled, this
# will print function names instead of addresses. If defined with a value
# of zero, the verbose code is compiled-in but disabled by default, and can
# be enabled with the debug.verbose_sysinit=1 tunable.
options VERBOSE_SYSINIT
#####################################################################
# SYSV IPC KERNEL PARAMETERS
#
# Maximum number of System V semaphores that can be used on the system at
2004-01-25 12:32:56 +00:00
# one time.
options SEMMNI=11
# Total number of semaphores system wide
options SEMMNS=61
# Total number of undo structures in system
options SEMMNU=31
# Maximum number of System V semaphores that can be used by a single process
2004-01-25 12:32:56 +00:00
# at one time.
options SEMMSL=61
# Maximum number of operations that can be outstanding on a single System V
2004-01-25 12:32:56 +00:00
# semaphore at one time.
options SEMOPM=101
# Maximum number of undo operations that can be outstanding on a single
2004-01-25 12:32:56 +00:00
# System V semaphore at one time.
options SEMUME=11
# Maximum number of shared memory pages system wide.
options SHMALL=1025
2004-01-25 12:32:56 +00:00
# Maximum size, in bytes, of a single System V shared memory region.
options SHMMAX=(SHMMAXPGS*PAGE_SIZE+1)
options SHMMAXPGS=1025
2004-01-25 12:32:56 +00:00
# Minimum size, in bytes, of a single System V shared memory region.
options SHMMIN=2
# Maximum number of shared memory regions that can be used on the system
2004-01-25 12:32:56 +00:00
# at one time.
options SHMMNI=33
# Maximum number of System V shared memory regions that can be attached to
2004-01-25 12:32:56 +00:00
# a single process at one time.
options SHMSEG=9
# Set the amount of time (in seconds) the system will wait before
# rebooting automatically when a kernel panic occurs. If set to (-1),
# the system will wait indefinitely until a key is pressed on the
# console.
options PANIC_REBOOT_WAIT_TIME=16
# Attempt to bypass the buffer cache and put data directly into the
# userland buffer for read operation when O_DIRECT flag is set on the
# file. Both offset and length of the read operation must be
2004-01-25 12:32:56 +00:00
# multiples of the physical media sector size.
#
options DIRECTIO
# Specify a lower limit for the number of swap I/O buffers. They are
# (among other things) used when bypassing the buffer cache due to
# DIRECTIO kernel option enabled and O_DIRECT flag set on file.
#
options NSWBUF_MIN=120
#####################################################################
# More undocumented options for linting.
# Note that documenting these is not considered an affront.
options CAM_DEBUG_DELAY
options DEBUG
# Kernel filelock debugging.
options LOCKF_DEBUG
# System V compatible message queues
# Please note that the values provided here are used to test kernel
# building. The defaults in the sources provide almost the same numbers.
# MSGSSZ must be a power of 2 between 8 and 1024.
options MSGMNB=2049 # Max number of chars in queue
options MSGMNI=41 # Max number of message queue identifiers
options MSGSEG=2049 # Max number of message segments
options MSGSSZ=16 # Size of a message segment
options MSGTQL=41 # Max number of messages in system
options NBUF=512 # Number of buffer headers
options SC_DEBUG_LEVEL=5 # Syscons debug level
options SC_RENDER_DEBUG # syscons rendering debugging
options VFS_BIO_DEBUG # VFS buffer I/O debugging
options KSTACK_MAX_PAGES=32 # Maximum pages to give the kernel stack
options KSTACK_USAGE_PROF
# Adaptec Array Controller driver options
2004-09-03 06:32:11 +00:00
options AAC_DEBUG # Debugging levels:
# 0 - quiet, only emit warnings
# 1 - noisy, emit major function
# points and things done
# 2 - extremely noisy, emit trace
# items in loops, etc.
# Resource Accounting
options RACCT
# Resource Limits
options RCTL
# Yet more undocumented options for linting.
options MAXFILES=999
# Random number generator
# Alternative algorithm.
#options RANDOM_FENESTRASX
# Allow the CSPRNG algorithm to be loaded as a module.
#options RANDOM_LOADABLE
# Select this to allow high-rate but potentially expensive
# harvesting of Slab-Allocator entropy. In very high-rate
# situations the value of doing this is dubious at best.
options RANDOM_ENABLE_UMA # slab allocator
# Select this to allow high-rate but potentially expensive
# harvesting of of the m_next pointer in the mbuf. Note that
# the m_next pointer is NULL except when receiving > 4K
# jumbo frames or sustained bursts by way of LRO. Thus in
# the common case it is stirring zero in to the entropy
# pool. In cases where it is not NULL it is pointing to one
# of a small (in the thousands to 10s of thousands) number
# of 256 byte aligned mbufs. Hence it is, even in the best
# case, a poor source of entropy. And in the absence of actual
# runtime analysis of entropy collection may mislead the user in
# to believe that substantially more entropy is being collected
# than in fact is - leading to a different class of security
# risk. In high packet rate situations ethernet entropy
# collection is also very expensive, possibly leading to as
# much as a 50% drop in packets received.
# This option is present to maintain backwards compatibility
# if desired, however it cannot be recommended for use in any
# environment.
options RANDOM_ENABLE_ETHER # ether_input
# Module to enable execution of application via emulators like QEMU
options IMGACT_BINMISC
# zlib I/O stream support
# This enables support for compressed core dumps.
options GZIO
geom_uzip(4), mkuzip(8): Add Zstd image mode The Zstd format bumps the CLOOP major number to 4 to avoid incompatibility with older systems. Support in geom_uzip(4) is conditional on the ZSTDIO kernel option, which is enabled in amd64 GENERIC, but not all in-tree configurations. mkuzip(8) was modified slightly to always initialize the nblocks + 1'th offset in the CLOOP file format. Previously, it was only initialized in the case where the final compressed block happened to be unaligned w.r.t. DEV_BSIZE. The "Fake" last+1 block change in r298619 means that the final compressed block's 'blen' was never correct unless the compressed uzip image happened to be BSIZE-aligned. This happened in about 1 out of every 512 cases. The zlib and lzma decompressors are probably tolerant of extra trash following the frame they were told to decode, but Zstd complains that the input size is incorrect. Correspondingly, geom_uzip(4) was modified slightly to avoid trashing the nblocks + 1'th offset when it is known to be initialized to a good value. This corrects the calculated final real cluster compressed length to match that printed by mkuzip(8). mkuzip(8) was refactored somewhat to reduce code duplication and increase ease of adding other compression formats. * Input block size validation was pulled out of individual compression init routines into main(). * Init routines now validate a user-provided compression level or select an algorithm-specific default, if none was provided. * A new interface for calculating the maximal compressed size of an incompressible input block was added for each driver. The generic code uses it to validate against MAXPHYS as well as to allocate compression result buffers in the generic code. * Algorithm selection is now driven by a table lookup, to increase ease of adding other formats in the future. mkuzip(8) gained the ability to explicitly specify a compression level with '-C'. The prior defaults -- 9 for zlib and 6 for lzma -- are maintained. The new zstd default is 9, to match zlib. Rather than select lzma or zlib with '-L' or its absense, respectively, a new argument '-A <algorithm>' is provided to select 'zlib', 'lzma', or 'zstd'. '-L' is considered deprecated, but will probably never be removed. All of the new features were documented in mkuzip.8; the page was also cleaned up slightly. Relnotes: yes
2019-08-13 23:32:56 +00:00
# zstd support
# This enables support for Zstd compressed core dumps, GEOM_UZIP images,
# and is required by zfs if statically linked.
options ZSTDIO
# BHND(4) drivers
options BHND_LOGLEVEL # Logging threshold level
# evdev interface
device evdev # input event device support
options EVDEV_SUPPORT # evdev support in legacy drivers
options EVDEV_DEBUG # enable event debug msgs
device uinput # install /dev/uinput cdev
options UINPUT_DEBUG # enable uinput debug msgs
Add support for encrypted kernel crash dumps. Changes include modifications in kernel crash dump routines, dumpon(8) and savecore(8). A new tool called decryptcore(8) was added. A new DIOCSKERNELDUMP I/O control was added to send a kernel crash dump configuration in the diocskerneldump_arg structure to the kernel. The old DIOCSKERNELDUMP I/O control was renamed to DIOCSKERNELDUMP_FREEBSD11 for backward ABI compatibility. dumpon(8) generates an one-time random symmetric key and encrypts it using an RSA public key in capability mode. Currently only AES-256-CBC is supported but EKCD was designed to implement support for other algorithms in the future. The public key is chosen using the -k flag. The dumpon rc(8) script can do this automatically during startup using the dumppubkey rc.conf(5) variable. Once the keys are calculated dumpon sends them to the kernel via DIOCSKERNELDUMP I/O control. When the kernel receives the DIOCSKERNELDUMP I/O control it generates a random IV and sets up the key schedule for the specified algorithm. Each time the kernel tries to write a crash dump to the dump device, the IV is replaced by a SHA-256 hash of the previous value. This is intended to make a possible differential cryptanalysis harder since it is possible to write multiple crash dumps without reboot by repeating the following commands: # sysctl debug.kdb.enter=1 db> call doadump(0) db> continue # savecore A kernel dump key consists of an algorithm identifier, an IV and an encrypted symmetric key. The kernel dump key size is included in a kernel dump header. The size is an unsigned 32-bit integer and it is aligned to a block size. The header structure has 512 bytes to match the block size so it was required to make a panic string 4 bytes shorter to add a new field to the header structure. If the kernel dump key size in the header is nonzero it is assumed that the kernel dump key is placed after the first header on the dump device and the core dump is encrypted. Separate functions were implemented to write the kernel dump header and the kernel dump key as they need to be unencrypted. The dump_write function encrypts data if the kernel was compiled with the EKCD option. Encrypted kernel textdumps are not supported due to the way they are constructed which makes it impossible to use the CBC mode for encryption. It should be also noted that textdumps don't contain sensitive data by design as a user decides what information should be dumped. savecore(8) writes the kernel dump key to a key.# file if its size in the header is nonzero. # is the number of the current core dump. decryptcore(8) decrypts the core dump using a private RSA key and the kernel dump key. This is performed by a child process in capability mode. If the decryption was not successful the parent process removes a partially decrypted core dump. Description on how to encrypt crash dumps was added to the decryptcore(8), dumpon(8), rc.conf(5) and savecore(8) manual pages. EKCD was tested on amd64 using bhyve and i386, mipsel and sparc64 using QEMU. The feature still has to be tested on arm and arm64 as it wasn't possible to run FreeBSD due to the problems with QEMU emulation and lack of hardware. Designed by: def, pjd Reviewed by: cem, oshogbo, pjd Partial review: delphij, emaste, jhb, kib Approved by: pjd (mentor) Differential Revision: https://reviews.freebsd.org/D4712
2016-12-10 16:20:39 +00:00
# Encrypted kernel crash dumps.
options EKCD
# Serial Peripheral Interface (SPI) support.
device spibus # Bus support.
device at45d # DataFlash driver
device cqspi #
device mx25l # SPIFlash driver
device n25q #
device spigen # Generic access to SPI devices from userland.
# Enable legacy /dev/spigenN name aliases for /dev/spigenX.Y devices.
options SPIGEN_LEGACY_CDEVNAME # legacy device names for spigen
# Compression supports.
device zlib # gzip/zlib compression/decompression library
device xz # xz_embedded LZMA de-compression library
# Kernel support for stats(3).
options STATS