freebsd-nq/sys/i386/conf/GENERIC

398 lines
14 KiB
Plaintext
Raw Normal View History

#
2000-01-21 20:19:18 +00:00
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
2002-08-01 17:21:18 +00:00
# http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
1999-08-28 01:08:13 +00:00
# $FreeBSD$
cpu I486_CPU
cpu I586_CPU
cpu I686_CPU
ident GENERIC
# To statically compile in device wiring instead of /boot/device.hints
#hints "GENERIC.hints" # Default places to look for devices.
# Use the following to compile in values accessible to the kernel
# through getenv() (or kenv(1) in userland). The format of the file
# is 'variable=value', see kenv(1)
#
# env "GENERIC.env"
makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
options SCHED_ULE # ULE scheduler
options PREEMPTION # Enable kernel thread preemption
options INET # InterNETworking
options INET6 # IPv6 communications protocols
options SCTP # Stream Control Transmission Protocol
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
2007-04-10 21:40:13 +00:00
options UFS_GJOURNAL # Enable gjournal-based UFS journaling
options MD_ROOT # MD is a potential root device
options NFSCLIENT # Network Filesystem Client
options NFSSERVER # Network Filesystem Server
options NFSLOCKD # Network Lock Manager
options NFS_ROOT # NFS usable as /, requires NFSCLIENT
options MSDOSFS # MSDOS Filesystem
options CD9660 # ISO 9660 Filesystem
options PROCFS # Process filesystem (requires PSEUDOFS)
options PSEUDOFS # Pseudo-filesystem framework
options GEOM_PART_GPT # GUID Partition Tables.
options GEOM_LABEL # Provides labelization
options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty)
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
2006-09-26 12:36:34 +00:00
options COMPAT_FREEBSD6 # Compatible with FreeBSD6
options COMPAT_FREEBSD7 # Compatible with FreeBSD7
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
options KTRACE # ktrace(1) support
options STACK # stack(9) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
options KBD_INSTALL_CDEV # install a CDEV entry in /dev
options STOP_NMI # Stop CPUS using NMI instead of IPI
options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4)
options AUDIT # Security event auditing
#options KDTRACE_HOOKS # Kernel DTrace hooks
# Debugging for use in -current
options KDB # Enable kernel debugger support.
options DDB # Support DDB.
options GDB # Support remote GDB.
options INVARIANTS # Enable calls of extra sanity checking
options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS
options WITNESS # Enable checks to detect deadlocks and cycles
options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed
# To make an SMP kernel, the next two lines are needed
options SMP # Symmetric MultiProcessor Kernel
device apic # I/O APIC
# CPU frequency control
device cpufreq
# Bus support.
device acpi
device eisa
2002-07-23 06:38:47 +00:00
device pci
# Floppy drives
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
1999-12-08 09:19:37 +00:00
# ATA and ATAPI devices
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
options ATA_STATIC_ID # Static device numbering
# SCSI Controllers
device ahb # EISA AHA1742 family
device ahc # AHA2940 and onboard AIC7xxx devices
options AHC_REG_PRETTY_PRINT # Print register bitfields in debug
# output. Adds ~128k to driver.
device ahd # AHA39320/29320 and onboard AIC79xx devices
options AHD_REG_PRETTY_PRINT # Print register bitfields in debug
# output. Adds ~215k to driver.
device amd # AMD 53C974 (Tekram DC-390(T))
device hptiop # Highpoint RocketRaid 3xxx series
device isp # Qlogic family
#device ispfw # Firmware for QLogic HBAs- normally a module
device mpt # LSI-Logic MPT-Fusion
#device ncr # NCR/Symbios Logic
device sym # NCR/Symbios Logic (newer chipsets + those of `ncr')
device trm # Tekram DC395U/UW/F DC315U adapters
device adv # Advansys SCSI adapters
device adw # Advansys wide SCSI adapters
device aha # Adaptec 154x SCSI adapters
device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60.
device bt # Buslogic/Mylex MultiMaster SCSI adapters
device ncv # NCR 53C500
device nsp # Workbit Ninja SCSI-3
device stg # TMC 18C30/18C50
# SCSI peripherals
device scbus # SCSI bus (required for SCSI)
device ch # SCSI media changers
device da # Direct Access (disks)
device sa # Sequential Access (tape etc)
device cd # CD
device pass # Passthrough device (direct SCSI access)
device ses # SCSI Environmental Services (and SAF-TE)
# RAID controllers interfaced to the SCSI subsystem
device amr # AMI MegaRAID
2005-03-31 20:21:43 +00:00
device arcmsr # Areca SATA II RAID
device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID
device ciss # Compaq Smart RAID 5*
device dpt # DPT Smartcache III, IV - See NOTES for options
2004-10-24 08:53:40 +00:00
device hptmv # Highpoint RocketRAID 182x
device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx
device iir # Intel Integrated RAID
device ips # IBM (Adaptec) ServeRAID
device mly # Mylex AcceleRAID/eXtremeRAID
device twa # 3ware 9000 series PATA/SATA RAID
# RAID controllers
device aac # Adaptec FSA RAID
device aacp # SCSI passthrough for aac (requires CAM)
device ida # Compaq Smart RAID
2006-03-29 09:57:22 +00:00
device mfi # LSI MegaRAID SAS
device mlx # Mylex DAC960 family
device pst # Promise Supertrak SX6000
device twe # 3ware ATA RAID
1999-04-19 10:18:34 +00:00
# atkbdc0 controls both the keyboard and the PS/2 mouse
device atkbdc # AT keyboard controller
device atkbd # AT keyboard
device psm # PS/2 mouse
device kbdmux # keyboard multiplexer
device vga # VGA video card driver
device splash # Splash screen and screen saver support
# syscons is the default console driver, resembling an SCO console
device sc
device agp # support several AGP chipsets
2000-07-25 08:25:48 +00:00
# Power management support (see NOTES for more options)
#device apm
# Add suspend/resume support for the i8254.
device pmtimer
# PCCARD (PCMCIA) support
# PCMCIA and cardbus bridge support
device cbb # cardbus (yenta) bridge
device pccard # PC Card (16-bit) bus
device cardbus # CardBus (32-bit) bus
# Serial (COM) ports
device uart # Generic UART driver
1999-02-11 06:07:27 +00:00
# Parallel port
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
device ppbus # Parallel port bus (required)
device lpt # Printer
device plip # TCP/IP over parallel
device ppi # Parallel port interface device
#device vpo # Requires scbus and da
# If you've got a "dumb" serial or parallel PCI card that is
# supported by the puc(4) glue driver, uncomment the following
# line to enable it (connects to sio, uart and/or ppc drivers):
#device puc
# PCI Ethernet NICs.
device de # DEC/Intel DC21x4x (``Tulip'')
2008-07-30 22:30:49 +00:00
device em # Intel PRO/1000 Gigabit Ethernet Family
device igb # Intel PRO/1000 PCIE Server Gigabit Family
device ixgb # Intel PRO/10GbE Ethernet Card
device le # AMD Am7900 LANCE and Am79C9xx PCnet
device ti # Alteon Networks Tigon I/II gigabit Ethernet
device txp # 3Com 3cR990 (``Typhoon'')
device vx # 3Com 3c590, 3c595 (``Vortex'')
# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device miibus # MII bus support
device ae # Attansic/Atheros L2 FastEthernet
device age # Attansic/Atheros L1 Gigabit Ethernet
Add ale(4), a driver for Atheros AR8121/AR8113/AR8114 PCIe ethernet controller. The controller is also known as L1E(AR8121) and L2E(AR8113/AR8114). Unlike its predecessor Attansic L1, AR8121/AR8113/AR8114 uses completely different Rx logic such that it requires separate driver. Datasheet for AR81xx is not available to open source driver writers but it shares large part of Tx and PHY logic of L1. I still don't understand some part of register meaning and some MAC statistics counters but the driver seems to have no critical issues for performance and stability. The AR81xx requires copy operation to pass received frames to upper stack such that ale(4) consumes a lot of CPU cycles than that of other controller. A couple of silicon bugs also adds more CPU cycles to address the known hardware bug. However, if you have fast CPU you can still saturate the link. Currently ale(4) supports the following hardware features. - MSI. - TCP Segmentation offload. - Hardware VLAN tag insertion/stripping with checksum offload. - Tx TCP/UDP checksum offload and Rx IP/TCP/UDP checksum offload. - Tx/Rx interrupt moderation. - Hardware statistics counters. - Jumbo frame. - WOL. AR81xx PCIe ethernet controllers are mainly found on ASUS EeePC or P5Q series of ASUS motherboards. Special thanks to Jeremy Chadwick who sent the hardware to me. Without his donation writing a driver for AR81xx would never have been possible. Big thanks to all people who reported feedback or tested patches. HW donated by: koitsu Tested by: bsam, Joao Barros <joao.barros <> gmail DOT com > Jan Henrik Sylvester <me <> janh DOT de > Ivan Brawley < ivan <> brawley DOT id DOT au >, CURRENT ML
2008-11-12 09:52:06 +00:00
device ale # Atheros AR8121/AR8113/AR8114 Ethernet
2006-04-10 20:04:22 +00:00
device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet
2004-05-02 18:57:29 +00:00
device bfe # Broadcom BCM440x 10/100 Ethernet
2003-09-10 18:54:59 +00:00
device bge # Broadcom BCM570xx Gigabit Ethernet
device dc # DEC/Intel 21143 and various workalikes
device et # Agere ET1310 10/100/Gigabit Ethernet
device fxp # Intel EtherExpress PRO/100B (82557, 82558)
device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet
device lge # Level 1 LXT1001 gigabit Ethernet
device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet
device nfe # nVidia nForce MCP on-board Ethernet
device nge # NatSemi DP83820 gigabit Ethernet
#device nve # nVidia nForce MCP on-board Ethernet Networking
device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le')
Take the support for the 8139C+/8169/8169S/8110S chips out of the rl(4) driver and put it in a new re(4) driver. The re(4) driver shares the if_rlreg.h file with rl(4) but is a separate module. (Ultimately I may change this. For now, it's convenient.) rl(4) has been modified so that it will never attach to an 8139C+ chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to match the 8169/8169S/8110S gigE chips. if_re.c contains the same basic code that was originally bolted onto if_rl.c, with the following updates: - Added support for jumbo frames. Currently, there seems to be a limit of approximately 6200 bytes for jumbo frames on transmit. (This was determined via experimentation.) The 8169S/8110S chips apparently are limited to 7.5K frames on transmit. This may require some more work, though the framework to handle jumbo frames on RX is in place: the re_rxeof() routine will gather up frames than span multiple 2K clusters into a single mbuf list. - Fixed bug in re_txeof(): if we reap some of the TX buffers, but there are still some pending, re-arm the timer before exiting re_txeof() so that another timeout interrupt will be generated, just in case re_start() doesn't do it for us. - Handle the 'link state changed' interrupt - Fix a detach bug. If re(4) is loaded as a module, and you do tcpdump -i re0, then you do 'kldunload if_re,' the system will panic after a few seconds. This happens because ether_ifdetach() ends up calling the BPF detach code, which notices the interface is in promiscuous mode and tries to switch promisc mode off while detaching the BPF listner. This ultimately results in a call to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init() to handle the IFF_PROMISC flag change. Unfortunately, calling re_init() here turns the chip back on and restarts the 1-second timeout loop that drives re_tick(). By the time the timeout fires, if_re.ko has been unloaded, which results in a call to invalid code and blows up the system. To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(), which stops the ioctl routine from trying to reset the chip. - Modified comments in re_rxeof() relating to the difference in RX descriptor status bit layout between the 8139C+ and the gigE chips. The layout is different because the frame length field was expanded from 12 bits to 13, and they got rid of one of the status bits to make room. - Add diagnostic code (re_diag()) to test for the case where a user has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some NICs have the REQ64# and ACK64# lines connected even though the board is 32-bit only (in this case, they should be pulled high). This fools the chip into doing 64-bit DMA transfers even though there is no 64-bit data path. To detect this, re_diag() puts the chip into digital loopback mode and sets the receiver to promiscuous mode, then initiates a single 64-byte packet transmission. The frame is echoed back to the host, and if the frame contents are intact, we know DMA is working correctly, otherwise we complain loudly on the console and abort the device attach. (At the moment, I don't know of any way to work around the problem other than physically modifying the board, so until/unless I can think of a software workaround, this will have do to.) - Created re(4) man page - Modified rlphy.c to allow re(4) to attach as well as rl(4). Note that this code works for the sample 8169/Marvell 88E1000 NIC that I have, but probably won't work for the 8169S/8110S chips. RealTek has sent me some sample NICs, but they haven't arrived yet. I will probably need to add an rlgphy driver to handle the on-board PHY in the 8169S/8110S (it needs special DSP initialization).
2003-09-08 02:11:25 +00:00
device re # RealTek 8139C+/8169/8169S/8110S
device rl # RealTek 8129/8139
device sf # Adaptec AIC-6915 (``Starfire'')
device sis # Silicon Integrated Systems SiS 900/SiS 7016
2004-05-02 18:57:29 +00:00
device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet
device ste # Sundance ST201 (D-Link DFE-550TX)
device stge # Sundance/Tamarack TC9021 gigabit Ethernet
device tl # Texas Instruments ThunderLAN
device tx # SMC EtherPower II (83c170 ``EPIC'')
device vge # VIA VT612x gigabit Ethernet
device vr # VIA Rhine, Rhine II
device wb # Winbond W89C840F
device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'')
# ISA Ethernet NICs. pccard NICs included.
device cs # Crystal Semiconductor CS89x0 NIC
# 'device ed' requires 'device miibus'
device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards
device ex # Intel EtherExpress Pro/10 and Pro/10+
device ep # Etherlink III based cards
device fe # Fujitsu MB8696x based cards
device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc.
2004-05-02 18:57:29 +00:00
device sn # SMC's 9000 series of Ethernet chips
device xe # Xircom pccard Ethernet
# Wireless NIC cards
2003-01-16 00:21:52 +00:00
device wlan # 802.11 support
options IEEE80211_DEBUG # enable debug msgs
options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's
device wlan_wep # 802.11 WEP support
device wlan_ccmp # 802.11 CCMP support
device wlan_tkip # 802.11 TKIP support
device wlan_amrr # AMRR transmit rate control algorithm
device an # Aironet 4500/4800 802.11 wireless NICs.
device ath # Atheros pci/cardbus NIC's
device ath_hal # pci/cardbus chip support
options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors
device ath_rate_sample # SampleRate tx rate control for ath
device ral # Ralink Technology RT2500 wireless NICs.
device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs.
#device wl # Older non 802.11 Wavelan wireless NIC.
# Pseudo 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 loop # Network loopback
device random # Entropy 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 ether # Ethernet support
device tun # Packet tunnel.
Integrate the new MPSAFE TTY layer to the FreeBSD operating system. The last half year I've been working on a replacement TTY layer for the FreeBSD kernel. The new TTY layer was designed to improve the following: - Improved driver model: The old TTY layer has a driver model that is not abstract enough to make it friendly to use. A good example is the output path, where the device drivers directly access the output buffers. This means that an in-kernel PPP implementation must always convert network buffers into TTY buffers. If a PPP implementation would be built on top of the new TTY layer (still needs a hooks layer, though), it would allow the PPP implementation to directly hand the data to the TTY driver. - Improved hotplugging: With the old TTY layer, it isn't entirely safe to destroy TTY's from the system. This implementation has a two-step destructing design, where the driver first abandons the TTY. After all threads have left the TTY, the TTY layer calls a routine in the driver, which can be used to free resources (unit numbers, etc). The pts(4) driver also implements this feature, which means posix_openpt() will now return PTY's that are created on the fly. - Improved performance: One of the major improvements is the per-TTY mutex, which is expected to improve scalability when compared to the old Giant locking. Another change is the unbuffered copying to userspace, which is both used on TTY device nodes and PTY masters. Upgrading should be quite straightforward. Unlike previous versions, existing kernel configuration files do not need to be changed, except when they reference device drivers that are listed in UPDATING. Obtained from: //depot/projects/mpsafetty/... Approved by: philip (ex-mentor) Discussed: on the lists, at BSDCan, at the DevSummit Sponsored by: Snow B.V., the Netherlands dcons(4) fixed by: kan
2008-08-20 08:31:58 +00:00
device pty # BSD-style compatibility pseudo ttys
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 "disks"
device gif # IPv6 and IPv4 tunneling
device faith # IPv6-to-IPv4 relaying (translation)
device firmware # firmware assist module
Borrow phk's axe and apply the next stage of config(8)'s evolution. Use Warner Losh's "hint" driver to decode ascii strings to fill the resource table at boot time. config(8) no longer generates an ioconf.c table - ie: the configuration no longer has to be compiled into the kernel. You can reconfigure your isa devices with the likes of this at loader(8) time: set hint.ed.0.port=0x320 userconfig will be rewritten to use this style interface one day and will move to /boot/userconfig.4th or something like that. It is still possible to statically compile in a set of hints into a kernel if you do not wish to use loader(8). See the "hints" directive in GENERIC as an example. All device wiring has been moved out of config(8). There is a set of helper scripts (see i386/conf/gethints.pl, and the same for alpha and pc98) that extract the 'at isa? port foo irq bar' from the old files and produces a hints file. If you install this file as /boot/device.hints (and update /boot/defaults/loader.conf - You can do a build/install in sys/boot) then loader will load it automatically for you. You can also compile in the hints directly with: hints "device.hints" as well. There are a few things that I'm not too happy with yet. Under this scheme, things like LINT would no longer be useful as "documentation" of settings. I have renamed this file to 'NOTES' and stored the example hints strings in it. However... this is not something that config(8) understands, so there is a script that extracts the build-specific data from the documentation file (NOTES) to produce a LINT that can be config'ed and built. A stack of man4 pages will need updating. :-/ Also, since there is no longer a difference between 'device' and 'pseudo-device' I collapsed the two together, and the resulting 'device' takes a 'number of units' for devices that still have it statically allocated. eg: 'device fe 4' will compile the fe driver with NFE set to 4. You can then set hints for 4 units (0 - 3). Also note that 'device fe0' will be interpreted as "zero units of 'fe'" which would be bad, so there is a config warning for this. This is only needed for old drivers that still have static limits on numbers of units. All the statically limited drivers that I could find were marked. Please exercise EXTREME CAUTION when transitioning! Moral support by: phk, msmith, dfr, asmodai, imp, and others
2000-06-13 22:28:50 +00:00
# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
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
# USB core support
device usb2_core
# USB controller support
device usb2_controller
device usb2_controller_ehci
device usb2_controller_ohci
device usb2_controller_uhci
# USB mass storage support
device usb2_storage
device usb2_storage_mass
# USB ethernet support, requires miibus
device usb2_ethernet
device usb2_ethernet_aue
device usb2_ethernet_axe
device usb2_ethernet_cdce
device usb2_ethernet_cue
device usb2_ethernet_kue
device usb2_ethernet_rue
device usb2_ethernet_dav
# USB wireless LAN support
device usb2_wlan
device usb2_wlan_rum
device usb2_wlan_ral
device usb2_wlan_zyd
# USB serial device support
device usb2_serial
device usb2_serial_ark
device usb2_serial_bsa
device usb2_serial_bser
device usb2_serial_chcom
device usb2_serial_cycom
device usb2_serial_foma
device usb2_serial_ftdi
device usb2_serial_gensa
device usb2_serial_ipaq
device usb2_serial_lpt
device usb2_serial_mct
device usb2_serial_modem
device usb2_serial_moscom
device usb2_serial_plcom
device usb2_serial_slcom
device usb2_serial_visor
device usb2_serial_vscom
# USB bluetooth support
#device usb2_bluetooth
#device usb2_bluetooth_ng
# USB input device support
device usb2_input
device usb2_input_hid
device usb2_input_kbd
device usb2_input_ms
# USB sound and MIDI device support
#device usb2_sound
# USB scanner support
device usb2_image
device usb2_scanner
# USB support (deprecated)
#device uhci # UHCI PCI->USB interface
#device ohci # OHCI PCI->USB interface
#device ehci # EHCI PCI->USB interface (USB 2.0)
#device usb # USB Bus (required)
#device udbp # USB Double Bulk Pipe devices
#device ugen # Generic
#device uhid # "Human Interface Devices"
#device ukbd # Keyboard
#device ulpt # Printer
#device umass # Disks/Mass storage - Requires scbus and da
#device ums # Mouse
#device ural # Ralink Technology RT2500USB wireless NICs
#device rum # Ralink Technology RT2501USB wireless NICs
#device zyd # ZyDAS zb1211/zb1211b wireless NICs
#device urio # Diamond Rio 500 MP3 player
#device uscanner # Scanners
# USB Serial devices
#device ucom # Generic com ttys
#device u3g # USB-based 3G modems (Option, Huawei, Sierra)
#device uark # Technologies ARK3116 based serial adapters
#device ubsa # Belkin F5U103 and compatible serial adapters
#device uftdi # For FTDI usb serial adapters
#device uipaq # Some WinCE based devices
#device uplcom # Prolific PL-2303 serial adapters
#device uslcom # SI Labs CP2101/CP2102 serial adapters
#device uvisor # Visor and Palm devices
#device uvscom # USB serial support for DDI pocket's PHS
# USB Ethernet, requires miibus
#device aue # ADMtek USB Ethernet
#device axe # ASIX Electronics USB Ethernet
#device cdce # Generic USB over Ethernet
#device cue # CATC USB Ethernet
#device kue # Kawasaki LSI USB Ethernet
#device rue # RealTek RTL8150 USB Ethernet
#device udav # Davicom DM9601E USB
2003-04-21 16:44:05 +00:00
# FireWire support
device firewire # FireWire bus code
device sbp # SCSI over FireWire (Requires scbus and da)
device fwe # Ethernet over FireWire (non-standard!)
device fwip # IP over FireWire (RFC 2734,3146)
device dcons # Dumb console driver
device dcons_crom # Configuration ROM for dcons