freebsd-skq/sys/conf/NOTES

2671 lines
94 KiB
Plaintext
Raw Normal View History

# $FreeBSD$
#
# 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 'hint.' are NOT for config(8), they go into your
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
# 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
#
# 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 max and default 'raw' I/O block device access sizes.
# Reads and writes will be split into DFLTPHYS chunks. Some applications
# have better performance with larger raw I/O access sizes. Typically
# MAXPHYS should be twice the size of DFLTPHYS. Note that certain VM
# parameters are derived from these values and making them too large
# can make an an unbootable kernel.
#
# The defaults are 64K and 128K respectively.
options DFLTPHYS=(64*1024)
options MAXPHYS=(128*1024)
# Options for the VM subsystem
# Deprecated options supported for backwards compatibility
#options PQ_NOOPT # No coloring
1997-01-16 07:43:27 +00:00
# This allows you to actually store this configuration file into
# the kernel binary itself, where it may be later read by saying:
2001-05-26 06:01:43 +00:00
# strings -n 3 /boot/kernel/kernel | sed -n 's/^___//p' > MYKERNEL
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
options GEOM_AES # Don't use, use GEOM_BDE
options GEOM_BDE # Disk encryption.
options GEOM_BSD # BSD disklabels
options GEOM_CACHE # Disk cache.
options GEOM_CONCAT # Disk concatenation.
options GEOM_ELI # Disk encryption.
options GEOM_FOX # Redundant path mitigation
options GEOM_GATE # Userland services.
options GEOM_JOURNAL # Journaling.
options GEOM_LABEL # Providers labelization.
options GEOM_MBR # DOS/MBR 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_GPT # GPT partitioning
options GEOM_PC98 # NEC PC9800 partitioning
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_SUNLABEL # Sun/Solaris partitioning
options GEOM_UZIP # Read-only compressed disks
options GEOM_VOL # Volume names from UFS superblock
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 is a new scheduler that has been designed for SMP and has some
# advantages for UP as well. It is intended to replace the 4BSD scheduler
# over time. NOTE: SCHED_ULE is currently considered experimental and is
# not recommended for production use at this time.
2003-01-26 05:35:54 +00:00
#
options SCHED_4BSD
Add scheduler CORE, the work I have done half a year ago, recent, I picked it up again. The scheduler is forked from ULE, but the algorithm to detect an interactive process is almost completely different with ULE, it comes from Linux paper "Understanding the Linux 2.6.8.1 CPU Scheduler", although I still use same word "score" as a priority boost in ULE scheduler. Briefly, the scheduler has following characteristic: 1. Timesharing process's nice value is seriously respected, timeslice and interaction detecting algorithm are based on nice value. 2. per-cpu scheduling queue and load balancing. 3. O(1) scheduling. 4. Some cpu affinity code in wakeup path. 5. Support POSIX SCHED_FIFO and SCHED_RR. Unlike scheduler 4BSD and ULE which using fuzzy RQ_PPQ, the scheduler uses 256 priority queues. Unlike ULE which using pull and push, the scheduelr uses pull method, the main reason is to let relative idle cpu do the work, but current the whole scheduler is protected by the big sched_lock, so the benefit is not visible, it really can be worse than nothing because all other cpu are locked out when we are doing balancing work, which the 4BSD scheduelr does not have this problem. The scheduler does not support hyperthreading very well, in fact, the scheduler does not make the difference between physical CPU and logical CPU, this should be improved in feature. The scheduler has priority inversion problem on MP machine, it is not good for realtime scheduling, it can cause realtime process starving. As a result, it seems the MySQL super-smack runs better on my Pentium-D machine when using libthr, despite on UP or SMP kernel.
2006-06-13 13:12:56 +00:00
#options SCHED_CORE
#options SCHED_ULE
#####################################################################
# SMP OPTIONS:
#
# SMP enables building of a Symmetric MultiProcessor Kernel.
# Mandatory:
options SMP # Symmetric MultiProcessor Kernel
# ADAPTIVE_MUTEXES changes the behavior of blocking mutexes to spin
# if the thread that currently owns the mutex is executing on another
# CPU. This behaviour is enabled by default, so this option can be used
# to disable it.
options NO_ADAPTIVE_MUTEXES
# ADAPTIVE_GIANT causes the Giant lock to also be made adaptive when
# running without NO_ADAPTIVE_MUTEXES. Normally, because Giant is assumed
# to be held for extended periods, contention on Giant will cause a thread
# to sleep rather than spinning.
options ADAPTIVE_GIANT
# 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
# MUTEX_WAKE_ALL changes the mutex unlock algorithm to wake all waiters
# when a contested mutex is released rather than just awaking the highest
# priority waiter.
options MUTEX_WAKE_ALL
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
# SMP Debugging Options:
#
# PREEMPTION allows the threads that are in the kernel to be preempted
# by higher priority threads. It helps with interactivity and
# allows interrupt threads to run sooner rather than waiting.
# WARNING! Only tested on amd64 and i386.
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.
2000-10-20 07:41:50 +00:00
# MUTEX_DEBUG enables various extra assertions in the mutex code.
# SLEEPQUEUE_PROFILING enables rudimentary profiling of the hash table
# used to hold active sleep queues.
# TURNSTILE_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
2000-10-20 07:41:50 +00:00
options MUTEX_DEBUG
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 internal hash tables.
options SLEEPQUEUE_PROFILING
options TURNSTILE_PROFILING
#####################################################################
2004-01-25 12:32:56 +00:00
# COMPATIBILITY OPTIONS
#
# Implement system calls compatible with 4.3BSD and older versions of
# FreeBSD. You probably do NOT want to remove this as much current code
# still relies on the 4.3 emulation. Note that some architectures that
# are supported by FreeBSD do not include support for certain important
# aspects of this compatibility option, namely those related to the
# signal delivery mechanism.
#
options COMPAT_43
1994-01-27 01:01:22 +00:00
# Old tty interface.
options COMPAT_43TTY
# 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
#
# 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
#
# 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
#
# 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
#
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
#
# KTR is a kernel tracing mechanism imported from BSD/OS. Currently
# it has no userland interface aside from a few sysctl's. It is
# enabled with the KTR option. KTR_ENTRIES defines the number of
# entries in the circular trace buffer; it must be a power of two.
# 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
2006-08-24 08:00:02 +00:00
# events, with bit X corresponding to CPU X. 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
# if KTR_VERBOSE is not defined.
#
options KTR
options KTR_ENTRIES=1024
options KTR_COMPILE=(KTR_INTR|KTR_PROC)
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
# 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 DIAGNOSTIC option is used to enable extra debugging information
# from some parts of the kernel. As this makes everything more noisy,
# it is disabled by default.
#
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
#
# RESTARTABLE_PANICS allows one to continue from a panic as if it were
# a call to the debugger to continue from a panic as instead. It is only
# useful if a kernel debugger is present. To restart from a panic, reset
# the panicstr variable to NULL and continue execution. This option is
# for development use only and should NOT be used in production systems
# to "workaround" a panic.
#
#options RESTARTABLE_PANICS
#
# This option let 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
#####################################################################
# PERFORMANCE MONITORING OPTIONS
#
# The hwpmc driver that allows the use of in-CPU performance monitoring
# counters for performance monitoring. The base kernel needs to 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_HOOKS # Other necessary kernel hooks
#####################################################################
# NETWORKING OPTIONS
#
# Protocol families:
# Only the INET (Internet) family is officially supported in FreeBSD.
#
options INET #Internet communications protocols
options INET6 #IPv6 communications protocols
options IPSEC #IP security
options IPSEC_ESP #IP security (crypto; define w/ IPSEC)
options IPSEC_DEBUG #debug for IP security
#
# Set IPSEC_FILTERGIF to force packets coming through a gif tunnel
# to be processed by any configured packet filtering (ipfw, ipf).
# The default is that packets coming from a tunnel are _not_ processed;
# they are assumed trusted.
#
# IPSEC history is preserved for such packets, and can be filtered
# using ipfw(8)'s 'ipsec' keyword, when this option is enabled.
#
#options IPSEC_FILTERGIF #filter ipsec packets from a tunnel
#options FAST_IPSEC #new IPsec (cannot define w/ IPSEC)
options IPX #IPX/SPX communications protocols
options IPXIP #IPX in IP encapsulation (not available)
options NCP #NetWare Core protocol
options NETATALK #Appletalk communications protocols
options NETATALKDEBUG #Appletalk debugging
#
# 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
#
# 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 premeier SCTP implementation in the NET
# 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 teased apart
# the V6 and V4.. since an association can span
# both a V6 and V4 address at the SAME time :-)
#
options SCTP
# There are bunches of options:
# this one turns on all sorts of
# nastly printing that you can
# do. Its all controled 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
#
# High speed enables sally floyds HS TCP optioin
# for congestion control increase, use only in
# very HS networks and with caution since I doubt
# it will compete fairly with peers. For the big-bad
# internet its best NOT to enable.
#
options SCTP_HIGH_SPEED
#
# This option turns off the CRC32c checksum. Basically
# You will not be able to talk to anyone else that
# has not done this. Its more for expermentation to
# see how much CPU the CRC32c really takes. Most new
# cards for TCP support checksum offload.. so this
# option gives you a "view" into what SCTP would be
# like with such an offload (which only exists in
# high in iSCSI boards so far). With the new
# splitting 8's algorithm its not as bad as it used
# to be.. but it does speed things up try only
# for in a captured lab environment :-)
options SCTP_WITH_NO_CSUM
#
# Logging, this is another debug tool thats way
# cool.. but does take resources so its off
# by default. To do any logging you must first
# enable SCTP_STAT_LOGGING. This gets the utilities
# into the code base that actually do the logging and
# alocates a hugh fixed circular buffer that logging
# uses (about 80,000 entires that are probably 8 long
# words or so long.. so it does take a LOT of memory).
# Its cool for real-time debugging though.
#
options SCTP_STAT_LOGGING
#
# 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 commited 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
#
options SCTP_LOG_MAXBURST
options SCTP_LOG_RWND
options SCTP_CWND_LOGGING
options SCTP_CWND_MONITOR
options SCTP_BLK_LOGGING
options SCTP_STR_LOGGING
options SCTP_FR_LOGGING
options SCTP_MAP_LOGGING
options SCTP_SACK_LOGGING
options SCTP_LOCK_LOGGING
options SCTP_RTTVAR_LOGGING
options SCTP_SB_LOGGING
options SCTP_EARLYFR_LOGGING
options SCTP_NAGLE_LOGGING
options SCTP_WAKE_LOGGING
options SCTP_RECV_RWND_LOGGING
options SCTP_SACK_RWND_LOGGING
options SCTP_MBUF_LOGGING
# 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
options ALTQ_CBQ # Class Bases Queueing
options ALTQ_RED # Random Early Detection
options ALTQ_RIO # RED In/Out
options ALTQ_HFSC # Hierarchical 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_ATMLLC
options NETGRAPH_ATM_ATMPIF
options NETGRAPH_BLUETOOTH # ng_bluetooth(4)
options NETGRAPH_BLUETOOTH_BT3C # ng_bt3c(4)
options NETGRAPH_BLUETOOTH_H4 # ng_h4(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_CISCO
options NETGRAPH_DEFLATE
options NETGRAPH_DEVICE
options NETGRAPH_ECHO
options NETGRAPH_EIFACE
options NETGRAPH_ETHER
options NETGRAPH_FEC
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
# MPPC compression requires proprietary files (not included)
#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_PPP
options NETGRAPH_PPPOE
options NETGRAPH_PPTPGRE
options NETGRAPH_PRED1
options NETGRAPH_RFC1490
options NETGRAPH_SOCKET
options NETGRAPH_SPLIT
2004-04-24 22:03:02 +00:00
options NETGRAPH_SPPP
options NETGRAPH_TAG
2005-06-10 08:05:13 +00:00
options NETGRAPH_TCPMSS
options NETGRAPH_TEE
options NETGRAPH_TTY
options NETGRAPH_UI
options NETGRAPH_VJC
# NgATM - Netgraph ATM
options NGATM_ATM
options NGATM_ATMBASE
options NGATM_SSCOP
options NGATM_SSCFU
options NGATM_UNI
options NGATM_CCATM
device mn # Munich32x/Falc54 Nx64kbit/sec cards.
1999-11-02 14:25:04 +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.
# The `ether' device provides generic code to handle
# Ethernets; it is MANDATORY when an Ethernet device driver is
# configured or token-ring is enabled.
# The `vlan' device implements the VLAN tagging of Ethernet frames
# according to IEEE 802.1Q. It requires `device miibus'.
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,
# ath, and awi drivers and will eventually be required by all 802.11 drivers.
# 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.
# 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.
# 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.
2001-06-19 17:00:55 +00:00
# The `fddi' device provides generic code to support FDDI.
# The `arcnet' device provides generic code to support Arcnet.
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 `sppp' device serves a similar role for certain types
# of synchronous PPP links (like `cx', `ar').
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 `sl' device implements the Serial Line IP (SLIP) service.
# The `ppp' device implements the Point-to-Point Protocol.
# The `bpf' device enables the Berkeley Packet Filter. Be
# aware of the legal and administrative consequences of enabling this
# option. The number of devices determines the maximum number of
# simultaneous BPF clients programs runnable. DHCP requires bpf.
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
2001-06-19 17:00:55 +00:00
# included for testing purposes. This shows up as the `ds' interface.
2000-09-01 21:24:07 +00:00
# The `tap' device is a pty-like virtual Ethernet interface
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 `tun' device implements (user-)ppp and nos-tun
# 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 two types of IP4 over IP4 tunneling:
# GRE and MOBILE, as specified in the RFC1701 and RFC2004.
2000-11-08 10:09:01 +00:00
# The XBONEHACK option allows the same pair of addresses to be configured on
# multiple gif 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 `faith' device captures packets sent to it and diverts them
# to the IPv4/IPv6 translation daemon.
# The `stf' device implements 6to4 encapsulation.
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 `ef' device provides support for multiple ethernet frame types
# specified via ETHER_* options. See ef(4) for details.
#
# 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).
# The PF_MPSAFE_UGID option enables a special workaround for a LOR with
# user/group rules that would otherwise lead to a deadlock. This has
# performance implications and should be used with care.
#
# The PPP_BSDCOMP option enables support for compress(1) style entire
# packet compression, the PPP_DEFLATE is for zlib/gzip style compression.
# PPP_FILTER enables code for filtering the ppp data stream and selecting
1999-07-06 19:23:32 +00:00
# events for resetting the demand dial activity timer - requires bpf.
# See pppd(8) for more details.
#
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 ether #Generic Ethernet
device vlan #VLAN support (needs miibus)
device wlan #802.11 support
device wlan_wep #802.11 WEP support
device wlan_ccmp #802.11 CCMP support
device wlan_tkip #802.11 TKIP support
device wlan_xauth #802.11 external authenticator support
device wlan_acl #802.11 MAC ACL support
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 token #Generic TokenRing
device fddi #Generic FDDI
device arcnet #Generic Arcnet
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 sppp #Generic Synchronous PPP
device loop #Network loopback device
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 bpf #Berkeley packet filter
device disc #Discard device (ds0, ds1, etc)
2000-09-01 21:24:07 +00:00
device tap #Virtual Ethernet driver
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 tun #Tunnel driver (ppp(8), nos-tun(8))
device sl #Serial Line IP
device gre #IP over IP tunneling
device if_bridge #Bridge interface
device pf #PF OpenBSD packet-filter firewall
device pflog #logging support interface for PF
device pfsync #synchronization interface for PF
options PF_MPSAFE_UGID #Workaround LOR with user/group rules
2005-02-22 13:50:02 +00:00
device carp #Common Address Redundancy Protocol
device enc #IPSec interface (needs FAST_IPSEC)
device ppp #Point-to-point protocol
options PPP_BSDCOMP #PPP BSD-compress support
options PPP_DEFLATE #PPP zlib/deflate/gzip support
options PPP_FILTER #enable bpf filtering (needs bpf)
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 ef # Multiple ethernet frames support
options ETHER_II # enable Ethernet_II frame
options ETHER_8023 # enable Ethernet_802.3 (Novell) frame
options ETHER_8022 # enable Ethernet_802.2 frame
options ETHER_SNAP # enable Ethernet_802.2/SNAP frame
# for IPv6
device gif #IPv6 and IPv4 tunneling
2000-11-08 10:09:01 +00:00
options XBONEHACK
device faith #for IPv6 and IPv4 translation
device stf #6to4 IPv6 over IPv4 encapsulation
#
# 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_FORWARD enables changing of the packet destination either
# to do some sort of policy routing or transparent proxying. Used by
# ``ipfw forward''. All redirections apply to locally generated
# packets too. Because of this great care is required when
# crafting the ruleset.
#
# IPFIREWALL_NAT adds support for in kernel nat in ipfw, and it requires
# LIBALIAS. To build an ipfw kld with nat support enabled, add
# "CFLAGS+= -DIPFIREWALL_NAT" to your make.conf.
#
# 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.
#
2001-06-19 17:07:15 +00:00
# TCPDEBUG enables code which keeps traces of the TCP state machine
# for sockets with the SO_DEBUG option set, which can then be examined
# using the trpt(8) utility.
#
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
2004-09-03 06:32:11 +00:00
options IPFIREWALL_FORWARD #packet destination changes
options IPFIREWALL_NAT #ipfw kernel nat 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 TCPDEBUG
# 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.
options MBUF_STRESS_TEST
# Statically Link in accept filters
options ACCEPT_FILTER_DATA
options ACCEPT_FILTER_HTTP
# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This
# prevents nmap et al. from identifying the TCP/IP stack, but breaks support
# for RFC1644 extensions and is not recommended for web servers.
#
options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN
# 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.
# This requires the use of 'device crypto', 'options FAST_IPSEC' or 'options
# IPSEC', and 'device cryptodev'.
#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 it is advisable to also have "options HZ=1000" to achieve a
# smoother scheduling of the traffic.
options DUMMYNET
1998-12-22 20:44:13 +00:00
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
# Zero copy sockets support. This enables "zero copy" for sending and
2004-06-26 17:19:44 +00:00
# receiving data via a socket. The send side works for any type of NIC,
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
# the receive side only works for NICs that support MTUs greater than the
# page size of your architecture and that support header splitting. See
# zero_copy(9) for more details.
options ZERO_COPY_SOCKETS
(this is an extract from src/share/examples/atm/README) =================================== HARP | Host ATM Research Platform =================================== HARP 3 What is this stuff? ------------------- The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center, Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed the Host ATM Research Platform (HARP) software, which allows IP hosts to communicate over ATM networks using standard protocols. It is intended to be a high-quality platform for IP/ATM research. HARP provides a way for IP hosts to connect to ATM networks. It supports standard methods of communication using IP over ATM. A host's standard IP software sends and receives datagrams via a HARP ATM interface. HARP provides functionality similar to (and typically replaces) vendor-provided ATM device driver software. HARP includes full source code, making it possible for researchers to experiment with different approaches to running IP over ATM. HARP is self-contained; it requires no other licenses or commercial software packages. HARP implements support for the IETF Classical IP model for using IP over ATM networks, including: o IETF ATMARP address resolution client o IETF ATMARP address resolution server o IETF SCSP/ATMARP server o UNI 3.1 and 3.0 signalling protocols o Fore Systems's SPANS signalling protocol What's supported ---------------- The following are supported by HARP 3: o ATM Host Interfaces - FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters - FORE Systems, Inc. PCA-200E ATM PCI Adapters - Efficient Networks, Inc. ENI-155p ATM PCI Adapters o ATM Signalling Protocols - The ATM Forum UNI 3.1 signalling protocol - The ATM Forum UNI 3.0 signalling protocol - The ATM Forum ILMI address registration - FORE Systems's proprietary SPANS signalling protocol - Permanent Virtual Channels (PVCs) o IETF "Classical IP and ARP over ATM" model - RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5" - RFC 1577, "Classical IP and ARP over ATM" - RFC 1626, "Default IP MTU for use over ATM AAL5" - RFC 1755, "ATM Signaling Support for IP over ATM" - RFC 2225, "Classical IP and ARP over ATM" - RFC 2334, "Server Cache Synchronization Protocol (SCSP)" - Internet Draft draft-ietf-ion-scsp-atmarp-00.txt, "A Distributed ATMARP Service Using SCSP" o ATM Sockets interface - The file atm-sockets.txt contains further information What's not supported -------------------- The following major features of the above list are not currently supported: o UNI point-to-multipoint support o Driver support for Traffic Control/Quality of Service o SPANS multicast and MPP support o SPANS signalling using Efficient adapters This software was developed under the sponsorship of the Defense Advanced Research Projects Agency (DARPA). Reviewed (lightly) by: phk Submitted by: Network Computing Services, Inc.
1998-09-15 11:44:44 +00:00
#
# ATM (HARP version) options
#
# ATM_CORE includes the base ATM functionality code. This must be included
# for ATM support.
#
# ATM_IP includes support for running IP over ATM.
#
# At least one (and usually only one) of the following signalling managers
(this is an extract from src/share/examples/atm/README) =================================== HARP | Host ATM Research Platform =================================== HARP 3 What is this stuff? ------------------- The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center, Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed the Host ATM Research Platform (HARP) software, which allows IP hosts to communicate over ATM networks using standard protocols. It is intended to be a high-quality platform for IP/ATM research. HARP provides a way for IP hosts to connect to ATM networks. It supports standard methods of communication using IP over ATM. A host's standard IP software sends and receives datagrams via a HARP ATM interface. HARP provides functionality similar to (and typically replaces) vendor-provided ATM device driver software. HARP includes full source code, making it possible for researchers to experiment with different approaches to running IP over ATM. HARP is self-contained; it requires no other licenses or commercial software packages. HARP implements support for the IETF Classical IP model for using IP over ATM networks, including: o IETF ATMARP address resolution client o IETF ATMARP address resolution server o IETF SCSP/ATMARP server o UNI 3.1 and 3.0 signalling protocols o Fore Systems's SPANS signalling protocol What's supported ---------------- The following are supported by HARP 3: o ATM Host Interfaces - FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters - FORE Systems, Inc. PCA-200E ATM PCI Adapters - Efficient Networks, Inc. ENI-155p ATM PCI Adapters o ATM Signalling Protocols - The ATM Forum UNI 3.1 signalling protocol - The ATM Forum UNI 3.0 signalling protocol - The ATM Forum ILMI address registration - FORE Systems's proprietary SPANS signalling protocol - Permanent Virtual Channels (PVCs) o IETF "Classical IP and ARP over ATM" model - RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5" - RFC 1577, "Classical IP and ARP over ATM" - RFC 1626, "Default IP MTU for use over ATM AAL5" - RFC 1755, "ATM Signaling Support for IP over ATM" - RFC 2225, "Classical IP and ARP over ATM" - RFC 2334, "Server Cache Synchronization Protocol (SCSP)" - Internet Draft draft-ietf-ion-scsp-atmarp-00.txt, "A Distributed ATMARP Service Using SCSP" o ATM Sockets interface - The file atm-sockets.txt contains further information What's not supported -------------------- The following major features of the above list are not currently supported: o UNI point-to-multipoint support o Driver support for Traffic Control/Quality of Service o SPANS multicast and MPP support o SPANS signalling using Efficient adapters This software was developed under the sponsorship of the Defense Advanced Research Projects Agency (DARPA). Reviewed (lightly) by: phk Submitted by: Network Computing Services, Inc.
1998-09-15 11:44:44 +00:00
# must be included (note that all signalling managers include PVC support):
# ATM_SIGPVC includes support for the PVC-only signalling manager `sigpvc'.
# ATM_SPANS includes support for the `spans' signalling manager, which runs
# the FORE Systems's proprietary SPANS signalling protocol.
# ATM_UNI includes support for the `uni30' and `uni31' signalling managers,
(this is an extract from src/share/examples/atm/README) =================================== HARP | Host ATM Research Platform =================================== HARP 3 What is this stuff? ------------------- The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center, Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed the Host ATM Research Platform (HARP) software, which allows IP hosts to communicate over ATM networks using standard protocols. It is intended to be a high-quality platform for IP/ATM research. HARP provides a way for IP hosts to connect to ATM networks. It supports standard methods of communication using IP over ATM. A host's standard IP software sends and receives datagrams via a HARP ATM interface. HARP provides functionality similar to (and typically replaces) vendor-provided ATM device driver software. HARP includes full source code, making it possible for researchers to experiment with different approaches to running IP over ATM. HARP is self-contained; it requires no other licenses or commercial software packages. HARP implements support for the IETF Classical IP model for using IP over ATM networks, including: o IETF ATMARP address resolution client o IETF ATMARP address resolution server o IETF SCSP/ATMARP server o UNI 3.1 and 3.0 signalling protocols o Fore Systems's SPANS signalling protocol What's supported ---------------- The following are supported by HARP 3: o ATM Host Interfaces - FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters - FORE Systems, Inc. PCA-200E ATM PCI Adapters - Efficient Networks, Inc. ENI-155p ATM PCI Adapters o ATM Signalling Protocols - The ATM Forum UNI 3.1 signalling protocol - The ATM Forum UNI 3.0 signalling protocol - The ATM Forum ILMI address registration - FORE Systems's proprietary SPANS signalling protocol - Permanent Virtual Channels (PVCs) o IETF "Classical IP and ARP over ATM" model - RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5" - RFC 1577, "Classical IP and ARP over ATM" - RFC 1626, "Default IP MTU for use over ATM AAL5" - RFC 1755, "ATM Signaling Support for IP over ATM" - RFC 2225, "Classical IP and ARP over ATM" - RFC 2334, "Server Cache Synchronization Protocol (SCSP)" - Internet Draft draft-ietf-ion-scsp-atmarp-00.txt, "A Distributed ATMARP Service Using SCSP" o ATM Sockets interface - The file atm-sockets.txt contains further information What's not supported -------------------- The following major features of the above list are not currently supported: o UNI point-to-multipoint support o Driver support for Traffic Control/Quality of Service o SPANS multicast and MPP support o SPANS signalling using Efficient adapters This software was developed under the sponsorship of the Defense Advanced Research Projects Agency (DARPA). Reviewed (lightly) by: phk Submitted by: Network Computing Services, Inc.
1998-09-15 11:44:44 +00:00
# which run the ATM Forum UNI 3.x signalling protocols.
#
# The `hfa' driver provides support for the FORE Systems, Inc.
# PCA-200E ATM PCI Adapter.
#
# The `harp' pseudo-driver makes all NATM interface drivers available to HARP.
#
options ATM_CORE #core ATM protocol family
options ATM_IP #IP over ATM support
options ATM_SIGPVC #SIGPVC signalling manager
options ATM_SPANS #SPANS signalling manager
options ATM_UNI #UNI signalling manager
device hfa #FORE PCA-200E ATM PCI
device harp #Pseudo-interface for NATM
(this is an extract from src/share/examples/atm/README) =================================== HARP | Host ATM Research Platform =================================== HARP 3 What is this stuff? ------------------- The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center, Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed the Host ATM Research Platform (HARP) software, which allows IP hosts to communicate over ATM networks using standard protocols. It is intended to be a high-quality platform for IP/ATM research. HARP provides a way for IP hosts to connect to ATM networks. It supports standard methods of communication using IP over ATM. A host's standard IP software sends and receives datagrams via a HARP ATM interface. HARP provides functionality similar to (and typically replaces) vendor-provided ATM device driver software. HARP includes full source code, making it possible for researchers to experiment with different approaches to running IP over ATM. HARP is self-contained; it requires no other licenses or commercial software packages. HARP implements support for the IETF Classical IP model for using IP over ATM networks, including: o IETF ATMARP address resolution client o IETF ATMARP address resolution server o IETF SCSP/ATMARP server o UNI 3.1 and 3.0 signalling protocols o Fore Systems's SPANS signalling protocol What's supported ---------------- The following are supported by HARP 3: o ATM Host Interfaces - FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters - FORE Systems, Inc. PCA-200E ATM PCI Adapters - Efficient Networks, Inc. ENI-155p ATM PCI Adapters o ATM Signalling Protocols - The ATM Forum UNI 3.1 signalling protocol - The ATM Forum UNI 3.0 signalling protocol - The ATM Forum ILMI address registration - FORE Systems's proprietary SPANS signalling protocol - Permanent Virtual Channels (PVCs) o IETF "Classical IP and ARP over ATM" model - RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5" - RFC 1577, "Classical IP and ARP over ATM" - RFC 1626, "Default IP MTU for use over ATM AAL5" - RFC 1755, "ATM Signaling Support for IP over ATM" - RFC 2225, "Classical IP and ARP over ATM" - RFC 2334, "Server Cache Synchronization Protocol (SCSP)" - Internet Draft draft-ietf-ion-scsp-atmarp-00.txt, "A Distributed ATMARP Service Using SCSP" o ATM Sockets interface - The file atm-sockets.txt contains further information What's not supported -------------------- The following major features of the above list are not currently supported: o UNI point-to-multipoint support o Driver support for Traffic Control/Quality of Service o SPANS multicast and MPP support o SPANS signalling using Efficient adapters This software was developed under the sponsorship of the Defense Advanced Research Projects Agency (DARPA). Reviewed (lightly) by: phk Submitted by: Network Computing Services, Inc.
1998-09-15 11:44:44 +00:00
#####################################################################
# FILESYSTEM OPTIONS
#
# Only the root, /usr, and /tmp filesystems need be statically
# compiled; everything else will be automatically loaded at mount
# time. (Exception: the UFS family--- FFS --- cannot
# currently be demand-loaded.) Some people still prefer to statically
# compile other filesystems as well.
#
# NB: The NULL, PORTAL, UMAP and UNION filesystems are known to be
# buggy, and WILL panic your system if you attempt to do anything with
# them. They are included here as an incentive for some enterprising
# soul to sit down and fix them.
#
# One of these is mandatory:
options FFS #Fast filesystem
options NFSCLIENT #Network File System client
1994-08-28 06:46:25 +00:00
# The rest are optional:
options CD9660 #ISO 9660 filesystem
options FDESCFS #File descriptor filesystem
options HPFS #OS/2 File system
options MSDOSFS #MS DOS File System (FAT, FAT32)
options NFSSERVER #Network File System server
options NTFS #NT File System
options NULLFS #NULL filesystem
# Broken (depends on NCP):
#options NWFS #NetWare filesystem
options PORTALFS #Portal 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
options UDF #Universal Disk Format
# Broken (seriously (functionally) broken):
#options UMAPFS #UID map filesystem
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.
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
# 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 or Netatalk, 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_GATHERDELAY=10 # Default write gather delay (msec)
options NFS_WDELAYHASHSIZ=16 # and with this
options NFS_DEBUG # Enable NFS Debugging
# Coda stuff:
options CODA #CODA filesystem.
device vcoda #coda minicache <-> venus comm.
2004-01-25 12:32:56 +00:00
# Use the old Coda 5.x venus<->kernel interface instead of the new
# realms-aware 6.x protocol.
#options CODA_COMPAT_5
#
# 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
#
# Add support for the ReiserFS filesystem (used in Linux). Currently,
# this is limited to read-only access.
#
options REISERFS
2005-12-12 02:01:51 +00:00
#
# Add support for the SGI XFS filesystem. Currently,
# this is limited to read-only access.
#
options XFS
# Use real implementations of the aio_* system calls. There are numerous
# stability and security issues in the current aio code that make it
# unsuitable for inclusion on machines with untrusted local users.
options VFS_AIO
# Cryptographically secure random number generator; /dev/random
device random
# The system memory devices; /dev/mem, /dev/kmem
device mem
# Optional character code conversion support with LIBICONV.
# Each option requires their base file system and LIBICONV.
options CD9660_ICONV
options MSDOSFS_ICONV
options NTFS_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
options MAC_IFOFF
options MAC_LOMAC
options MAC_MLS
options MAC_NONE
options MAC_PARTITION
options MAC_PORTACL
options MAC_SEEOTHERUIDS
options MAC_STUB
options MAC_TEST
#####################################################################
# CLOCK OPTIONS
# The granularity of operation is controlled by the kernel option HZ whose
# default value (100) means a granularity of 10ms (1s/HZ).
# Some subsystems, such as DUMMYNET, might benefit from a smaller
# granularity such as 1ms or less, for a smoother scheduling of packets.
# Consider, however, that reducing the granularity too much might
# cause excessive overhead in clock interrupt processing,
# potentially causing ticks to be missed and thus actually reducing
# the accuracy of operation.
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
#####################################################################
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. (See also option GEOM_VOL for a different solution to this
# problem.)
# 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:
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
hint.scbus.0.at="ahc0"
hint.scbus.1.at="ahc1"
hint.scbus.1.bus="0"
hint.scbus.3.at="ahc2"
hint.scbus.3.bus="0"
hint.scbus.2.at="ahc2"
hint.scbus.2.bus="1"
hint.da.0.at="scbus0"
hint.da.0.target="0"
hint.da.0.unit="0"
hint.da.1.at="scbus3"
hint.da.1.target="1"
hint.da.2.at="scbus2"
hint.da.2.target="3"
hint.sa.1.at="scbus1"
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.
#
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 "unknown" device (uk? in pre-2.0.5) is now part of the base SCSI
# configuration as the "pass" driver.
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 #SCSI Environmental Services (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
# CAM OPTIONS:
# debugging options:
# -- NOTE -- If you specify one of the bus/target/lun options, you must
# specify them all!
# CAMDEBUG: When defined enables debugging macros
# CAM_DEBUG_BUS: Debug the given bus. Use -1 to debug all busses.
# CAM_DEBUG_TARGET: Debug the given target. Use -1 to debug all targets.
# CAM_DEBUG_LUN: Debug the given lun. Use -1 to debug all luns.
# CAM_DEBUG_FLAGS: OR together CAM_DEBUG_INFO, CAM_DEBUG_TRACE,
# CAM_DEBUG_SUBTRACE, and CAM_DEBUG_CDB
#
# 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_BUS=-1
options CAM_DEBUG_TARGET=-1
options CAM_DEBUG_LUN=-1
options CAM_DEBUG_FLAGS=(CAM_DEBUG_INFO|CAM_DEBUG_TRACE|CAM_DEBUG_CDB)
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 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
# build a topology with the SES device that's on the box these drives
# are in....
options SES_ENABLE_PASSTHROUGH
#####################################################################
# MISCELLANEOUS DEVICES AND OPTIONS
# The `pty' device usually turns out to be ``effectively mandatory'',
# as it is required for `telnetd', `rlogind', `screen', `emacs', and
# `xterm', among others.
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 pty #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
# Maximum size of a tty or pty input buffer.
options TTYHOG=8193
#####################################################################
# HARDWARE DEVICE CONFIGURATION
# For ISA the required hints are listed.
# EISA, MCA, PCI and pccard 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
options FB_DEBUG # Frame buffer debugging
device splash # Splash screen and screen saver support
# Various screen savers.
device blank_saver
device daemon_saver
device dragon_saver
device fade_saver
device fire_saver
device green_saver
device logo_saver
device rain_saver
device snake_saver
device star_saver
device warp_saver
2006-08-24 08:00:02 +00:00
# The syscons console driver (SCO color console compatible).
device sc
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
hint.sc.0.at="isa"
options MAXCONS=16 # number of virtual consoles
options SC_ALT_MOUSE_IMAGE # simplified mouse cursor in text mode
options SC_DFLT_FONT # compile font in
makeoptions SC_DFLT_FONT=cp850
options SC_DISABLE_KDBKEY # disable `debug' key
options SC_DISABLE_REBOOT # disable reboot key sequence
options SC_HISTORY_SIZE=200 # number of history buffer lines
options SC_MOUSE_CHAR=0x3 # char code for text mode mouse cursor
options SC_PIXEL_MODE # add support for the raster text mode
# The following options will let you change the default colors of syscons.
options SC_NORM_ATTR=(FG_GREEN|BG_BLACK)
options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
options SC_KERNEL_CONS_ATTR=(FG_RED|BG_BLACK)
options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)
# The following options will let you change the default behaviour of
# cut-n-paste feature
options SC_CUT_SPACES2TABS # convert leading spaces into tabs
options SC_CUT_SEPCHARS=\"x09\" # set of characters that delimit words
# (default is single space - \"x20\")
# If you have a two button mouse, you may want to add the following option
# to use the right button of the mouse to paste text.
options SC_TWOBUTTON_MOUSE
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
# You can selectively disable features in syscons.
options SC_NO_CUTPASTE
options SC_NO_FONT_LOADING
options SC_NO_HISTORY
options SC_NO_MODE_CHANGE
options SC_NO_SYSMOUSE
options SC_NO_SUSPEND_VTYSWITCH
# `flags' for sc
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
# 0x80 Put the video card in the VESA 800x600 dots, 16 color mode
# 0x100 Probe for a keyboard device periodically if one is not present
#
# Optional devices:
#
#
# SCSI host adapters:
#
# adv: All Narrow SCSI bus AdvanSys controllers.
1998-10-07 03:42:44 +00:00
# adw: Second Generation AdvanSys controllers including the ADV940UW.
# aha: Adaptec 154x/1535/1640
# ahb: Adaptec 174x EISA controllers
# 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.
# aic: Adaptec 6260/6360, APA-1460 (PC Card), NEC PC9801-100 (C-BUS)
# amd: Support for the AMD 53C974 SCSI host adapter chip as found on devices
# such as the Tekram DC-390(T).
# bt: Most Buslogic controllers: including BT-445, BT-54x, BT-64x, BT-74x,
# BT-75x, BT-946, BT-948, BT-956, BT-958, SDC3211B, SDC3211F, SDC3222F
2004-06-10 05:43:36 +00:00
# esp: NCR53c9x. Only for SBUS hardware right now.
# 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
# mpt: LSI-Logic MPT/Fusion 53c1020 or 53c1030 Ultra4
# or FC9x9 Fibre Channel host adapters.
# ncr: NCR 53C810, 53C825 self-contained SCSI 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.
# trm: Tekram DC395U/UW/F DC315U adapters.
# wds: WD7000
#
# Note that the order is important in order for Buslogic ISA/EISA cards to be
# probed correctly.
#
device bt
hint.bt.0.at="isa"
hint.bt.0.port="0x330"
device adv
hint.adv.0.at="isa"
device adw
device aha
hint.aha.0.at="isa"
device aic
hint.aic.0.at="isa"
device ahb
device ahc
2002-06-06 16:35:58 +00:00
device ahd
device amd
2004-06-10 05:43:36 +00:00
device esp
device isp
2001-03-03 19:39:15 +00:00
hint.isp.0.disable="1"
hint.isp.0.role="3"
hint.isp.0.prefer_iomap="1"
hint.isp.0.prefer_memmap="1"
hint.isp.0.fwload_disable="1"
hint.isp.0.ignore_nvram="1"
hint.isp.0.fullduplex="1"
hint.isp.0.topology="lport"
hint.isp.0.topology="nport"
hint.isp.0.topology="lport-only"
hint.isp.0.topology="nport-only"
# we can't get u_int64_t types, nor can we get strings if it's got
# a leading 0x, hence this silly dodge.
hint.isp.0.portwnn="w50000000aaaa0000"
hint.isp.0.nodewnn="w50000000aaaa0001"
device ispfw
device mpt
device ncr
device sym
device trm
device wds
hint.wds.0.at="isa"
hint.wds.0.port="0x350"
hint.wds.0.irq="11"
hint.wds.0.drq="6"
# 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
# The adw driver will attempt to use memory mapped I/O for all PCI
# controllers that have it configured only if this option is set.
options ADW_ALLOW_MEMIO
# Options used in dev/isp/ (Qlogic SCSI/FC driver).
#
# ISP_TARGET_MODE - enable target mode operation
#
options ISP_TARGET_MODE=1
#
2006-04-18 22:43:46 +00:00
# ISP_DEFAULT_ROLES - default role (none, target, init, both)
#
options ISP_DEFAULT_ROLES=3
# Options used in dev/sym/ (Symbios SCSI driver).
#options SYM_SETUP_LP_PROBE_MAP #-Low Priority Probe Map (bits)
# Allows the ncr to take precedence
# 1 (1<<0) -> 810a, 860
# 2 (1<<1) -> 825a, 875, 885, 895
2004-01-25 12:32:56 +00:00
# 4 (1<<2) -> 895a, 896, 1510d
#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]
# The 'dpt' driver provides support for old DPT controllers (http://www.dpt.com/).
# These have hardware RAID-{0,1,5} support, and do multi-initiator I/O.
# The DPT controllers are commonly re-licensed under other brand-names -
# some controllers by Olivetti, Dec, HP, AT&T, SNI, AST, Alphatronic, NEC and
# Compaq are actually DPT controllers.
#
# See src/sys/dev/dpt for debugging and other subtle options.
# DPT_MEASURE_PERFORMANCE Enables a set of (semi)invasive metrics. Various
# instruments are enabled. The tools in
# /usr/sbin/dpt_* assume these to be enabled.
# DPT_HANDLE_TIMEOUTS Normally device timeouts are handled by the DPT.
# If you ant the driver to handle timeouts, enable
# this option. If your system is very busy, this
# option will create more trouble than solve.
# DPT_TIMEOUT_FACTOR Used to compute the excessive amount of time to
# wait when timing out with the above option.
# DPT_DEBUG_xxxx These are controllable from sys/dev/dpt/dpt.h
# DPT_LOST_IRQ When enabled, will try, once per second, to catch
# any interrupt that got lost. Seems to help in some
# DPT-firmware/Motherboard combinations. Minimal
# cost, great benefit.
# DPT_RESET_HBA Make "reset" actually reset the controller
# instead of fudging it. Only enable this if you
# are 100% certain you need it.
device dpt
# DPT options
#!CAM# options DPT_MEASURE_PERFORMANCE
#!CAM# options DPT_HANDLE_TIMEOUTS
options DPT_TIMEOUT_FACTOR=4
options DPT_LOST_IRQ
options DPT_RESET_HBA
#
# Compaq "CISS" RAID controllers (SmartRAID 5* series)
# These controllers have a SCSI-like interface, and require the
# CAM infrastructure.
#
device ciss
#
# Intel Integrated RAID controllers.
# This driver was developed and is maintained by Intel. Contacts
# at Intel for this driver are
# "Kannanthanam, Boji T" <boji.t.kannanthanam@intel.com> and
# "Leubner, Achim" <achim.leubner@intel.com>.
#
device iir
#
# Mylex AcceleRAID and eXtremeRAID controllers with v6 and later
# firmware. These controllers have a SCSI-like interface, and require
# the CAM infrastructure.
#
device mly
#
# 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
device amr # AMI MegaRAID
2006-03-29 09:57:22 +00:00
device mfi # LSI MegaRAID SAS
2006-10-21 04:13:20 +00:00
options MFI_DEBUG
#
# 3ware ATA RAID
#
device twe # 3ware ATA RAID
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
#
2000-08-13 14:25:33 +00:00
# The 'ATA' driver supports all ATA and ATAPI devices, including PC Card
# devices. You only need one "device ata" for it to find all
# PCI and PC Card ATA/ATAPI devices on modern machines.
device ata
device atadisk # ATA disk drives
device ataraid # ATA RAID drives
device atapicd # ATAPI CDROM drives
device atapifd # ATAPI floppy drives
device atapist # ATAPI tape drives
device atapicam # emulate ATAPI devices as SCSI ditto via CAM
# needs CAM to be present (scbus & pass)
2000-08-13 14:25:33 +00:00
#
# For older non-PCI, non-PnPBIOS systems, these are the hints lines to add:
hint.ata.0.at="isa"
hint.ata.0.port="0x1f0"
hint.ata.0.irq="14"
hint.ata.1.at="isa"
hint.ata.1.port="0x170"
hint.ata.1.irq="15"
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 following options are valid on the ATA driver:
#
# ATA_STATIC_ID: controller numbering is static ie depends on location
# else the device numbers are dynamically allocated.
options ATA_STATIC_ID
#
2000-08-13 14:25:33 +00:00
# Standard floppy disk controllers and floppy tapes, supports
# the Y-E DATA External FDD (PC Card)
#
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 fdc
hint.fdc.0.at="isa"
hint.fdc.0.port="0x3F0"
hint.fdc.0.irq="6"
hint.fdc.0.drq="2"
#
# FDC_DEBUG enables floppy debugging. Since the debug output is huge, you
# gotta turn it actually on by setting the variable fd_debug with DDB,
# however.
options FDC_DEBUG
#
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
# Activate this line if you happen to have an Insight floppy tape.
# Probing them proved to be dangerous for people with floppy disks only,
# so it's "hidden" behind a flag:
#hint.fdc.0.flags="1"
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
# Specify floppy devices
hint.fd.0.at="fdc0"
hint.fd.0.drive="0"
hint.fd.1.at="fdc0"
hint.fd.1.drive="1"
#
# uart: newbusified driver for serial interfaces. It consolidates the sio(4),
# sab(4) and zs(4) drivers.
#
device uart
# Options for uart(4)
options UART_PPS_ON_CTS # Do time pulse capturing using CTS
# instead of DCD.
# The following hint should only be used for pure ISA devices. It is not
# needed otherwise. Use of hints is strongly discouraged.
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.
hint.uart.0.port="0x3f8"
hint.uart.0.flags="0x10"
hint.uart.0.baud="115200"
# `flags' for serial drivers that support consoles like sio(4) and 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. For sio(4)
# specifically, the 0x20 flag can also be set (see above).
# Currently, at most one unit can have console support; the
# first one (in config file order) with this flag set is
# preferred. Setting this flag for sio0 gives the old behaviour.
# 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 on a serial 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.
options ALT_BREAK_TO_DEBUGGER
# Serial Communications Controller
# Supports the Siemens SAB 82532 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 some PCI 10/100 ethernet NICs,
# namely those which use MII-compliant transceivers or implement
2004-06-26 17:19:44 +00:00
# transceiver control interfaces that operate like an MII. Adding
# "device miibus0" to the kernel config pulls in support for
# the generic miibus API and all of the PHY drivers, including a
# generic one for PHYs that aren't specifically handled by an
# individual driver.
device miibus
# an: Aironet 4500/4800 802.11 wireless adapters. Supports the PCMCIA,
# PCI and ISA varieties.
# awi: Support for IEEE 802.11 PC Card devices using the AMD Am79C930 and
# Harris (Intersil) Chipset with PCnetMobile firmware by AMD.
# 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.
# cm: Arcnet SMC COM90c26 / SMC COM90c56
# (and SMC COM90c66 in '56 compatibility mode) adapters.
# cnw: Xircom CNW/Netware Airsurfer PC Card adapter
# 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.
# de: Digital Equipment DC21040
# em: Intel Pro/1000 Gigabit Ethernet 82542, 82543, 82544 based adapters.
# ep: 3Com 3C509, 3C529, 3C556, 3C562D, 3C563D, 3C572, 3C574X, 3C579, 3C589
# and PC Card devices using these chipsets.
# ex: Intel EtherExpress Pro/10 and other i82595-based adapters,
# Olicom Ethernet PC Card devices.
# fe: Fujitsu MB86960A/MB86965A Ethernet
# fea: DEC DEFEA EISA FDDI adapter
# fpa: Support for the Digital DEFPA PCI FDDI. `device fddi' is also needed.
# 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)
2004-08-14 22:38:50 +00:00
# hme: Sun HME (Happy Meal Ethernet)
# 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.
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.
# lmc: Support for the LMC/SBE wide-area network interface cards.
# 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.
# pcn: Support for PCI fast ethernet adapters based on the AMD Am79c97x
# PCnet-FAST, PCnet-FAST+, PCnet-FAST III, PCnet-PRO and PCnet-Home
# chipsets. These can also be handled by the le(4) driver if the
# pcn(4) driver is left out of the kernel. The le(4) driver does not
# support the additional features like the MII bus and burst mode of
# the PCnet-FAST and greater chipsets though.
# 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.
# sf: Support for Adaptec Duralink PCI fast ethernet adapters based on the
# Adaptec AIC-6915 "starfire" controller.
# This includes dual and quad port cards, as well as one 100baseFX card.
# Most of these are 64-bit PCI devices, except for one single port
# card which is 32-bit.
# sis: Support for NICs based on the Silicon Integrated Systems SiS 900,
# SiS 7016 and NS DP83815 PCI fast ethernet controller chips.
# sbsh: Support for Granch SBNI16 SHDSL modem PCI adapters
# 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.
# sn: Support for ISA and PC Card Ethernet devices using the
# SMC91C90/92/94/95 chips.
# 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.
# tl: Support for the Texas Instruments TNETE100 series 'ThunderLAN'
# cards and integrated ethernet controllers. This includes several
# Compaq Netelligent 10/100 cards and the built-in ethernet controllers
# in several Compaq Prosignia, Proliant and Deskpro systems. It also
# supports several Olicom 10Mbps and 10/100 boards.
2004-06-26 17:19:44 +00:00
# tx: SMC 9432 TX, BTX and FTX cards. (SMC EtherPower II series)
# txp: Support for 3Com 3cR990 cards with the "Typhoon" chipset
# vr: Support for various fast ethernet adapters based on the VIA
# Technologies VT3043 `Rhine I' and VT86C100A `Rhine II' chips,
2004-01-25 12:32:56 +00:00
# including the D-Link DFE530TX (see 'rl' for DFE530TX+), the Hawking
# Technologies PN102TX, and the AOpen/Acer ALN-320.
# vx: 3Com 3C590 and 3C595
# wb: Support for fast ethernet adapters based on the Winbond W89C840F chip.
# Note: this is not the same as the Winbond W89C940F, which is a
# NE2000 clone.
# wi: Lucent WaveLAN/IEEE 802.11 PCMCIA adapters. Note: this supports both
# the PCMCIA and ISA cards: the ISA card is really a PCMCIA to ISA
# bridge with a PCMCIA adapter plugged into it.
# xe: Xircom/Intel EtherExpress Pro100/16 PC Card ethernet controller,
# Accton Fast EtherCard-16, Compaq Netelligent 10/100 PC Card,
# Toshiba 10/100 Ethernet PC Card, Xircom 16-bit Ethernet + Modem 56
# 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
# Order for ISA/EISA devices is important here
device cm
hint.cm.0.at="isa"
hint.cm.0.port="0x2e0"
hint.cm.0.irq="9"
hint.cm.0.maddr="0xdc000"
device ep
device ex
device fe
hint.fe.0.at="isa"
hint.fe.0.port="0x300"
device fea
device sn
hint.sn.0.at="isa"
hint.sn.0.port="0x300"
hint.sn.0.irq="10"
device an
device awi
device cnw
device wi
device xe
# PCI Ethernet NICs that use the common MII bus controller code.
device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet
device bfe # Broadcom BCM440x 10/100 Ethernet
device bge # Broadcom BCM570xx Gigabit Ethernet
device dc # DEC/Intel 21143 and various workalikes
device fxp # Intel EtherExpress PRO/100B (82557, 82558)
hint.fxp.0.prefer_iomap="0"
2004-08-14 22:38:50 +00:00
device hme # Sun HME (Happy Meal Ethernet)
device lge # Level 1 LXT1001 gigabit Ethernet
device my # Myson Fast Ethernet (MTD80X, MTD89X)
device nge # NatSemi DP83820 gigabit Ethernet
device rl # RealTek 8129/8139
device pcn # AMD Am79C97x PCI 10/100 NICs
device sf # Adaptec AIC-6915 (``Starfire'')
device sbsh # Granch SBNI16 SHDSL modem
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 ti # Alteon Networks Tigon I/II gigabit Ethernet
device tl # Texas Instruments ThunderLAN
2000-09-11 20:10:16 +00:00
device tx # SMC EtherPower II (83c170 ``EPIC'')
device vr # VIA Rhine, Rhine II
device wb # Winbond W89C840F
device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'')
# PCI Ethernet NICs.
device de # DEC/Intel DC21x4x (``Tulip'')
device le # AMD Am7900 LANCE and Am79C9xx PCnet
device txp # 3Com 3cR990 (``Typhoon'')
device vx # 3Com 3c590, 3c595 (``Vortex'')
# PCI FDDI NICs.
device fpa
# PCI WAN adapters.
device lmc
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
# Use "private" jumbo buffers allocated exclusively for the ti(4) driver.
# This option is incompatible with the TI_JUMBO_HDRSPLIT option below.
#options TI_PRIVATE_JUMBOS
# 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.
options TI_JUMBO_HDRSPLIT
# 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=12 # mbuf cluster shift in bits, 12 == 4KB
options MSIZE=512 # mbuf size in bytes
1997-05-09 12:19:06 +00:00
#
2000-11-07 09:31:28 +00:00
# ATM related options (Cranor version)
# (note: this driver cannot be used with the HARP ATM stack)
1997-05-09 12:19:06 +00:00
#
# The `en' device provides support for Efficient Networks (ENI)
# ENI-155 PCI midway cards, and the Adaptec 155Mbps PCI ATM cards (ANA-59x0).
#
# The `hatm' device provides support for Fore/Marconi HE155 and HE622
# ATM PCI cards.
#
# The `fatm' device provides support for Fore PCA200E ATM PCI cards.
#
# The `patm' device provides support for IDT77252 based cards like
# ProSum's ProATM-155 and ProATM-25 and IDT's evaluation boards.
#
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
# atm device provides generic atm functions and is required for
1997-05-09 12:19:06 +00:00
# atm devices.
# NATM enables the netnatm protocol family that can be used to
1997-05-09 12:19:06 +00:00
# bypass TCP/IP.
#
# utopia provides the access to the ATM PHY chips and is required for en,
# hatm and fatm.
#
1997-05-09 12:19:06 +00:00
# the current driver supports only PVC operations (no atm-arp, no multicast).
# for more details, please read the original documents at
# http://www.ccrc.wustl.edu/pub/chuck/tech/bsdatm/bsdatm.html
1997-05-09 12:19:06 +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 atm
2000-11-07 09:31:28 +00:00
device en
device fatm #Fore PCA200E
device hatm #Fore/Marconi HE155/622
device patm #IDT77252 cards (ProATM and IDT)
device utopia #ATM PHY driver
options NATM #native ATM
options LIBMBPOOL #needed by patm, iatm
#
# Sound drivers
#
# sound: The generic sound driver.
#
device sound
#
# snd_*: Device-specific drivers.
#
# The flags of the device tells 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...).
#
2006-01-04 17:19:28 +00:00
# snd_ad1816: Analog Devices AD1816 ISA PnP/non-PnP.
# snd_als4000: Avance Logic ALS4000 PCI.
# snd_atiixp: ATI IXP 200/300/400 PCI.
# snd_au88x0 Aureal Vortex 1/2/Advantage PCI. This driver
# lacks support for playback and recording.
# snd_audiocs: Crystal Semiconductor CS4231 SBus/EBus. Only
# for sparc64.
# snd_cmi: CMedia CMI8338/CMI8738 PCI.
# snd_cs4281: Crystal Semiconductor CS4281 PCI.
# snd_csa: Crystal Semiconductor CS461x/428x PCI. (except
# 4281)
# snd_ds1: Yamaha DS-1 PCI.
# 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_ess: Ensoniq ESS ISA PnP/non-PnP, to be used in
# conjunction with snd_sbc.
# snd_fm801: Forte Media FM801 PCI.
# snd_gusc: Gravis UltraSound ISA PnP/non-PnP.
# snd_hda: Intel High Definition Audio (Controller) and
# compatible.
# snd_ich: Intel ICH PCI and some more audio controllers
# embedded in a chipset, for example nVidia
# nForce controllers.
# snd_maestro: ESS Technology Maestro-1/2x PCI.
# snd_maestro3: ESS Technology Maestro-3/Allegro PCI.
# snd_mss: Microsoft Sound System ISA PnP/non-PnP.
# snd_neomagic: Neomagic 256 AV/ZX PCI.
# snd_sb16: Creative SoundBlaster16, to be used in
2006-08-24 08:00:02 +00:00
# conjunction with snd_sbc.
# snd_sb8: Creative SoundBlaster (pre-16), to be used in
2006-08-24 08:00:02 +00:00
# conjunction with snd_sbc.
# snd_sbc: Creative SoundBlaster ISA PnP/non-PnP.
# Supports ESS and Avance ISA chips as well.
2006-09-30 17:59:08 +00:00
# snd_spicds: SPI codec driver, needed by Envy24/Envy24HT drivers.
# snd_solo: ESS Solo-1x PCI.
# snd_t4dwave: Trident 4DWave DX/NX PCI, Sis 7018 PCI and Acer Labs
# M5451 PCI.
# snd_via8233: VIA VT8233x PCI.
# snd_via82c686: VIA VT82C686A PCI.
# snd_vibes: S3 Sonicvibes PCI.
# snd_uaudio: USB audio.
device snd_ad1816
device snd_als4000
device snd_atiixp
#device snd_au88x0
#device snd_audiocs
device snd_cmi
device snd_cs4281
device snd_csa
device snd_ds1
device snd_emu10k1
device snd_emu10kx
options SND_EMU10KX_MULTICHANNEL
device snd_envy24
2006-09-30 17:59:08 +00:00
device snd_envy24ht
device snd_es137x
device snd_ess
device snd_fm801
device snd_gusc
device snd_hda
device snd_ich
device snd_maestro
device snd_maestro3
device snd_mss
device snd_neomagic
device snd_sb16
device snd_sb8
device snd_sbc
device snd_solo
2006-09-30 17:59:08 +00:00
device snd_spicds
device snd_t4dwave
device snd_via8233
device snd_via82c686
device snd_vibes
device snd_uaudio
2006-08-24 08:00:02 +00:00
# For non-PnP sound cards:
hint.pcm.0.at="isa"
hint.pcm.0.irq="10"
hint.pcm.0.drq="1"
hint.pcm.0.flags="0x0"
hint.sbc.0.at="isa"
hint.sbc.0.port="0x220"
hint.sbc.0.irq="5"
hint.sbc.0.drq="1"
hint.sbc.0.flags="0x15"
hint.gusc.0.at="isa"
hint.gusc.0.port="0x220"
hint.gusc.0.irq="5"
hint.gusc.0.drq="1"
hint.gusc.0.flags="0x13"
#
# IEEE-488 hardware:
2005-09-15 13:28:33 +00:00
# pcii: PCIIA cards (uPD7210 based isa cards)
# tnt4882: National Instruments PCI-GPIB card.
device pcii
hint.pcii.0.at="isa"
hint.pcii.0.port="0x2e1"
hint.pcii.0.irq="5"
hint.pcii.0.drq="1"
2005-09-15 13:28:33 +00:00
device tnt4882
#
1995-07-16 08:55:04 +00:00
# Miscellaneous hardware:
#
# scd: Sony CD-ROM using proprietary (non-ATAPI) interface
2002-10-04 07:14:19 +00:00
# mcd: Mitsumi CD-ROM using proprietary (non-ATAPI) interface
# bktr: Brooktree bt848/848a/849a/878/879 video capture and TV Tuner board
2001-02-01 09:57:59 +00:00
# cy: Cyclades serial driver
# joy: joystick (including IO DATA PCJOY PC Card joystick)
# rc: RISCom/8 multiport card
# rp: Comtrol Rocketport(ISA/PCI) - single card
# si: Specialix SI/XIO 4-32 port terminal multiplexor
# Notes on the Comtrol Rocketport driver:
#
# The exact values used for rp0 depend on how many boards you have
# in the system. The manufacturer's sample configs are listed as:
#
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 rp # core driver support
#
# Comtrol Rocketport ISA single card
# hint.rp.0.at="isa"
# hint.rp.0.port="0x280"
#
# If instead you have two ISA cards, one installed at 0x100 and the
# second installed at 0x180, then you should add the following to
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
# your kernel probe hints:
# hint.rp.0.at="isa"
# hint.rp.0.port="0x100"
# hint.rp.1.at="isa"
# hint.rp.1.port="0x180"
#
# For 4 ISA cards, it might be something like this:
# hint.rp.0.at="isa"
# hint.rp.0.port="0x180"
# hint.rp.1.at="isa"
# hint.rp.1.port="0x100"
# hint.rp.2.at="isa"
# hint.rp.2.port="0x340"
# hint.rp.3.at="isa"
# hint.rp.3.port="0x240"
#
# For PCI cards, you need no hints.
2002-10-04 07:14:19 +00:00
# Mitsumi CD-ROM
2004-01-25 12:32:56 +00:00
device mcd
2002-10-04 07:14:19 +00:00
hint.mcd.0.at="isa"
hint.mcd.0.port="0x300"
# for the Sony CDU31/33A CDROM
device scd
hint.scd.0.at="isa"
hint.scd.0.port="0x230"
2006-08-24 08:00:02 +00:00
device joy # PnP aware, hints for non-PnP only
hint.joy.0.at="isa"
hint.joy.0.port="0x201"
device rc
hint.rc.0.at="isa"
hint.rc.0.port="0x220"
hint.rc.0.irq="12"
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 rp
hint.rp.0.at="isa"
hint.rp.0.port="0x280"
device si
options SI_DEBUG
hint.si.0.at="isa"
hint.si.0.maddr="0xd0000"
hint.si.0.irq="12"
#
# The 'bktr' device is a PCI video capture device using the Brooktree
# bt848/bt848a/bt849a/bt878/bt879 chipset. When used with a TV Tuner it forms a
# TV card, e.g. Miro PC/TV, Hauppauge WinCast/TV WinTV, VideoLogic Captivator,
# Intel Smart Video III, AverMedia, IMS Turbo, FlyVideo.
#
# options OVERRIDE_CARD=xxx
# options OVERRIDE_TUNER=xxx
# options OVERRIDE_MSP=1
# options OVERRIDE_DBX=1
# These options can be used to override the auto detection
# The current values for xxx are found in src/sys/dev/bktr/bktr_card.h
# Using sysctl(8) run-time overrides on a per-card basis can be made
#
# options BROOKTREE_SYSTEM_DEFAULT=BROOKTREE_PAL
# or
# options BROOKTREE_SYSTEM_DEFAULT=BROOKTREE_NTSC
2004-06-26 17:19:44 +00:00
# Specifies the default video capture mode.
# This is required for Dual Crystal (28&35Mhz) boards where PAL is used
# to prevent hangs during initialisation, e.g. VideoLogic Captivator PCI.
#
# options BKTR_USE_PLL
# This is required for PAL or SECAM boards with a 28Mhz crystal and no 35Mhz
# crystal, e.g. some new Bt878 cards.
#
# options BKTR_GPIO_ACCESS
# This enable IOCTLs which give user level access to the GPIO port.
#
# options BKTR_NO_MSP_RESET
# Prevents the MSP34xx reset. Good if you initialise the MSP in another OS first
#
# options BKTR_430_FX_MODE
# Switch Bt878/879 cards into Intel 430FX chipset compatibility mode.
#
# options BKTR_SIS_VIA_MODE
# Switch Bt878/879 cards into SIS/VIA chipset compatibility mode which is
# needed for some old SiS and VIA chipset motherboards.
# This also allows Bt878/879 chips to work on old OPTi (<1997) chipset
# motherboards and motherboards with bad or incomplete PCI 2.1 support.
# As a rough guess, old = before 1998
#
# options BKTR_NEW_MSP34XX_DRIVER
# Use new, more complete initialization scheme for the msp34* soundchip.
# Should fix stereo autodetection if the old driver does only output
# mono sound.
#
# options BKTR_USE_FREEBSD_SMBUS
# Compile with FreeBSD SMBus implementation
#
# Brooktree driver has been ported to the new I2C framework. Thus,
# you'll need to have the following 3 lines in the kernel config.
# device smbus
# device iicbus
# device iicbb
# device iicsmb
# The iic and smb devices are only needed if you want to control other
# I2C slaves connected to the external connector of some cards.
#
device bktr
#
# PC Card/PCMCIA and Cardbus
#
# pccbb: pci/cardbus bridge implementing YENTA interface
# pccard: pccard slots
# cardbus: cardbus slots
device cbb
device pccard
device cardbus
#
# 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
# bktr brooktree848 I2C hardware 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
#
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 smb
#
# 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.
#
# Supported interfaces:
# bktr brooktree848 I2C software interface
#
# Other:
# iicbb generic I2C bit-banging code (needed by lpbb, bktr)
#
device iicbus # Bus support, required for ic/iic/iicsmb below.
device iicbb
device ic
device iic
device iicsmb # smb over i2c bridge
# 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:
# vpo Iomega Zip Drive
# Requires SCSI disk support ('scbus' and 'da'), best
# performance is achieved with ports in EPP 1.9 mode.
# 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
#
# 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 VP0_DEBUG # ZIP/ZIP+ debug
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
hint.ppc.0.at="isa"
hint.ppc.0.irq="7"
device ppbus
device vpo
device lpt
device plip
device ppi
device pps
device lpbb
device pcfclock
# Kernel BOOTP support
options BOOTP # Use BOOTP to obtain IP address/hostname
# Requires NFSCLIENT 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
#
# Add software watchdog routines.
#
options SW_WATCHDOG
#
# 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 sysctls "vm.defer_swapspace_pageouts" and
# "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 change a
# number of function calls to pass around the relevant data. This is
# not at all useful unless you are debugging lock code. Also note
# that it is likely to break e.g. fstat(1) unless you recompile your
# userland with -DDEBUG_LOCKS as well.
#
options DEBUG_LOCKS
#####################################################################
# USB support
# UHCI controller
device uhci
# OHCI controller
device ohci
# EHCI controller
device ehci
# SL811 Controller
device slhci
# General USB code (mandatory for USB)
device usb
#
# USB Double Bulk Pipe devices
device udbp
# USB Fm Radio
device ufm
# Generic USB device driver
device ugen
# Human Interface Device (anything with buttons and dials)
device uhid
# USB keyboard
device ukbd
# USB printer
device ulpt
# USB Iomega Zip 100 Drive (Requires scbus and da)
device umass
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
2006-08-24 08:00:02 +00:00
# Diamond Rio 500 MP3 player
device urio
# USB scanners
device uscanner
#
# USB serial support
device ucom
# USB support for Technologies ARK3116 based serial adapters
device uark
# USB support for Belkin F5U103 and compatible serial adapters
device ubsa
# USB support for BWCT console serial adapters
device ubser
# 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 Visor and Palm devices
device uvisor
# USB serial support for DDI pocket's PHS
device uvscom
#
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
#
# 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
# debugging options for the USB subsystem
#
options USB_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=it.iso
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 FAST_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
device cryptodev # /dev/crypto for access to h/w
device rndtest # FIPS 140-2 entropy tester
device hifn # Hifn 7951, 7781, etc.
options HIFN_DEBUG # enable debugging support: hw.hifn.debug
options HIFN_RNDTEST # enable rndtest support
device ubsec # Broadcom 5501, 5601, 58xx
options UBSEC_DEBUG # enable debugging support: hw.ubsec.debug
options UBSEC_RNDTEST # enable rndtest support
#####################################################################
#
# Embedded system options:
#
# An embedded system might want to run something other than init.
options INIT_PATH=/sbin/init:/stand/sysinstall
# 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
#
# 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.
options VERBOSE_SYSINIT
#####################################################################
# SYSV IPC KERNEL PARAMETERS
#
# Maximum number of entries in a semaphore map.
options SEMMAP=31
# 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 are not considered an affront.
options CAM_DEBUG_DELAY
# VFS cluster debugging.
options CLUSTERDEBUG
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 SCSI_NCR_DEBUG
options SCSI_NCR_MAX_SYNC=10000
options SCSI_NCR_MAX_WIDE=1
options SCSI_NCR_MYADDR=7
options SC_DEBUG_LEVEL=5 # Syscons debug level
options SC_RENDER_DEBUG # syscons rendering debugging
options SHOW_BUSYBUFS # List buffers that prevent root unmount
options SLIP_IFF_OPTS
options VFS_BIO_DEBUG # VFS buffer I/O debugging
options KSTACK_MAX_PAGES=32 # Maximum pages to give the kernel stack
# 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.
# Yet more undocumented options for linting.
# BKTR_ALLOC_PAGES has no effect except to cause warnings, and
# BROOKTREE_ALLOC_PAGES hasn't actually been superseded by it, since the
# driver still mostly spells this option BROOKTREE_ALLOC_PAGES.
##options BKTR_ALLOC_PAGES=(217*4+1)
options BROOKTREE_ALLOC_PAGES=(217*4+1)
options MAXFILES=999