分类： BSD
2005-09-02 14:45:23
Traditionally, FreeBSD has had what is called a “monolithic” kernel. This means that the kernel was one large program, supported a fixed list of devices, and if you wanted to change the kernel's behavior then you had to compile a new kernel, and then reboot your computer with the new kernel.
Today, FreeBSD is rapidly moving to a model where much of the kernel's functionality is contained in modules which can be dynamically loaded and unloaded from the kernel as necessary. This allows the kernel to adapt to new hardware suddenly becoming available (such as PCMCIA cards in a laptop), or for new functionality to be brought into the kernel that was not necessary when the kernel was originally compiled. This is known as a modular kernel.
Despite this, it is still necessary to carry out some static kernel configuration. In some cases this is because the functionality is so tied to the kernel that it can not be made dynamically loadable. In others it may simply be because no one has yet taken the time to write a dynamic loadable kernel module for that functionality.
Building a custom kernel is one of the most important rites of passage nearly every BSD user must endure. This process, while time consuming, will provide many benefits to your FreeBSD system. Unlike the GENERIC kernel, which must support a wide range of hardware, a custom kernel only contains support for your PC's hardware. This has a number of benefits, such as:
Faster boot time. Since the kernel will only probe the hardware you have on your system, the time it takes your system to boot can decrease dramatically.
Lower memory usage. A custom kernel often uses less memory than the GENERIC kernel, which is important because the kernel must always be present in real memory. For this reason, a custom kernel is especially useful on a system with a small amount of RAM.
Additional hardware support. A custom kernel allows you to add in support for devices which are not present in the GENERIC kernel, such as sound cards.
First, let us take a quick tour of the kernel build directory. All directories mentioned will be relative to the main /usr/src/sys directory, which is also accessible through the path name /sys. There are a number of subdirectories here representing different parts of the kernel, but the most important for our purposes are arch/conf, where you will edit your custom kernel configuration, and compile, which is the staging area where your kernel will be built. arch represents one of i386, alpha, amd64, ia64, powerpc, sparc64, or pc98 (an alternative development branch of PC hardware, popular in Japan). Everything inside a particular architecture's directory deals with that architecture only; the rest of the code is machine independent code common to all platforms to which FreeBSD could potentially be ported. Notice the logical organization of the directory structure, with each supported device, file system, and option in its own subdirectory. Versions of FreeBSD prior to 5.X support only the i386, alpha and pc98 architectures.
This chapter assumes that you are using the i386 architecture in the examples. If this is not the case for your situation, make appropriate adjustments to the path names for your system's architecture.
Note: If there is not a /usr/src/sys directory on your system, then the kernel source has not been installed. The easiest way to do this is by running sysinstall (/stand/sysinstall in FreeBSD versions older than 5.2) as root, choosing Configure, then Distributions, then src, then sys. If you have an aversion to sysinstall and you have access to an “official” FreeBSD CDROM, then you can also install the source from the command line:
# mount /cdrom
# mkdir -p /usr/src/sys
# ln -s /usr/src/sys /sys
# cat /cdrom/src/ssys.[a-d]* | tar -xzvf -
Next, move to the arch/conf directory and copy the GENERIC configuration file to the name you want to give your kernel. For example:
# cd /usr/src/sys/i386/conf
# cp GENERIC MYKERNEL
Traditionally, this name is in all capital letters and, if you are maintaining multiple FreeBSD machines with different hardware, it is a good idea to name it after your machine's hostname. We will call it MYKERNEL for the purpose of this example.
Tip: Storing your kernel configuration file directly under /usr/src can be a bad idea. If you are experiencing problems it can be tempting to just delete /usr/src and start again. After doing this, it usually only takes a few seconds for you to realize that you have deleted your custom kernel configuration file. Also, do not edit GENERIC directly, as it may get overwritten the next time you update your source tree, and your kernel modifications will be lost.
You might want to keep your kernel configuration file elsewhere, and then create a symbolic link to the file in the i386 directory.
For example:
# cd /usr/src/sys/i386/conf
# mkdir /root/kernels
# cp GENERIC /root/kernels/MYKERNEL
# ln -s /root/kernels/MYKERNEL
Now, edit MYKERNEL with your favorite text editor. If you are just starting out, the only editor available will probably be vi, which is too complex to explain here, but is covered well in many books in the . However, FreeBSD does offer an easier editor called ee which, if you are a beginner, should be your editor of choice. Feel free to change the comment lines at the top to reflect your configuration or the changes you have made to differentiate it from GENERIC.
If you have built a kernel under SunOS™ or some other BSD operating system, much of this file will be very familiar to you. If you are coming from some other operating system such as DOS, on the other hand, the GENERIC configuration file might seem overwhelming to you, so follow the descriptions in the section slowly and carefully.
Note: If you sync your source tree with the latest sources of the FreeBSD project, be sure to always check the file /usr/src/UPDATING before you perform any update steps. This file describes any important issues or areas requiring special attention within the updated source code. /usr/src/UPDATING always matches your version of the FreeBSD source, and is therefore more up to date with new information than this handbook.
You must now compile the source code for the kernel. There are two procedures you can use to do this, and the one you will use depends on why you are rebuilding the kernel and the version of FreeBSD that you are running.
If you have installed only the kernel source code, use procedure 1.
If you are running a FreeBSD version prior to 4.0, and you are not upgrading to FreeBSD 4.0 or higher using the make buildworld procedure, use procedure 1.
If you are building a new kernel without updating the source code (perhaps just to add a new option, such as IPFIREWALL) you can use either procedure.
If you are rebuilding the kernel as part of a make buildworld process, use procedure 2.
If you have not upgraded your source tree in any way since the last time you successfully completed a buildworld-installworld cycle (you have not run CVSup, CTM, or used anoncvs), then it is safe to use the config, make depend, make, make install sequence.
Procedure 1. Building a Kernel the “Traditional” Way
Run to generate the kernel source code.
# /usr/sbin/config MYKERNEL
Change into the build directory. will print the name of this directory after being run as above.
# cd ../compile/MYKERNEL
For FreeBSD versions prior to 5.0, use the following form instead:
# cd ../../compile/MYKERNEL
Compile the kernel.
# make depend
# make
Install the new kernel.
# make install
Procedure 2. Building a Kernel the “New” Way
Change to the /usr/src directory.
# cd /usr/src
Compile the kernel.
# make buildkernel KERNCONF=MYKERNEL
Install the new kernel.
# make installkernel KERNCONF=MYKERNEL
Note: This method of kernel building requires full source files. If you only installed the kernel source, use the traditional method, as described above.
Note: In FreeBSD 4.2 and older you must replace KERNCONF= with KERNEL=. 4.2-STABLE that was fetched before Feb 2nd, 2001 does not recognize KERNCONF=.
The new kernel will be copied to the /boot/kernel directory as /boot/kernel/kernel and the old kernel will be moved to /boot/kernel.old/kernel. Now, shutdown the system and reboot to use your new kernel. If something goes wrong, there are some instructions at the end of this chapter that you may find useful. Be sure to read the section which explains how to recover in case your new kernel .
Note: In FreeBSD 4.X and earlier, kernels are installed in /kernel, modules in /modules, and old kernels are backed up in /kernel.old. Other files relating to the boot process, such as the boot and configuration are stored in /boot. Third party or custom modules can be placed in /modules, although users should be aware that keeping modules in sync with the compiled kernel is very important. Modules not intended to run with the compiled kernel may result in instability or incorrectness.
Note: If you have added any new devices (such as sound cards) and you are running FreeBSD 4.X or previous versions, you may have to add some device nodes to your /dev directory before you can use them. For more information, take a look at section later on in this chapter.
Note: NOTES does not exist in FreeBSD 4.X. Instead, see the LINT file for detailed explanations of options and devices in GENERIC. LINT served two purposes in 4.X: to provide a reference for choosing kernel options when building a custom kernel, and to provide a kernel configuration with as many tweakable options tweaked to non-default values as possible. The reason behind this was that such a configuration helped (and still does) a lot when testing new code and changes to existing code that may cause conflicts with other parts of the kernel. However, the kernel configuration framework went through some heavy changes in 5.X; one example of this is that the driver configuration options were moved to a hints file so that they could be changed and loaded dynamically at boot time, and LINT could not contain those hints anymore. For this and other reasons, the LINT file was renamed to NOTES and retained mostly the first reason for its existence: documenting the available options for user convenience.
In FreeBSD 5.X and later versions you can still generate a buildable LINT file by typing:
# cd /usr/src/sys/i386/conf && make LINT
The following is an example of the GENERIC kernel configuration file with various additional comments where needed for clarity. This example should match your copy in /usr/src/sys/i386/conf/GENERIC fairly closely.
machine i386
This is the machine architecture. It must be either alpha, amd64, i386, ia64, pc98, powerpc, or sparc64.
cpu I486_CPU
cpu I586_CPU
cpu I686_CPU
The above option specifies the type of CPU you have in your system. You may have multiple instances of the CPU line (if, for example, you are not sure whether you should use I586_CPU or I686_CPU), but for a custom kernel it is best to specify only the CPU you have. If you are unsure of your CPU type, you can check the /var/run/dmesg.boot file to view your boot messages.
Support for I386_CPU is still provided in the source of FreeBSD, but it is disabled by default in both -STABLE and -CURRENT. This means that to install FreeBSD with a 386-class cpu, you now have the following options:
Install an older FreeBSD release and rebuild from source as described in .
Build the userland and kernel on a newer machine and install on the 386 using the precompiled /usr/obj files (see for details).
Roll your own release of FreeBSD which includes I386_CPU support in the kernels of the installation CD-ROM.
The first of these options is probably the easiest of all, but you will need a lot of disk space which, on a 386-class machine, may be difficult to find.
ident GENERIC
This is the identification of the kernel. You should change this to whatever you named your kernel, i.e. MYKERNEL if you have followed the instructions of the previous examples. The value you put in the ident string will print when you boot up the kernel, so it is useful to give the new kernel a different name if you want to keep it separate from your usual kernel (e.g., you want to build an experimental kernel).
#To statically compile in device wiring instead of /boot/device.hints
#hints "GENERIC.hints" # Default places to look for devices.
In FreeBSD 5.X and newer versions the device.hints(5) is used to configure options of the device drivers. The default location that will check at boot time is /boot/device.hints. Using the hints option you can compile these hints statically into your kernel. Then there is no need to create a device.hints file in /boot.
#makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
The normal build process of FreeBSD does not include debugging information when building the kernel and strips most symbols after the resulting kernel is linked, to save some space at the install location. If you are going to do tests of kernels in the -CURRENT branch or develop changes of your own for the FreeBSD kernel, you might want to uncomment this line. It will enable the use of the -g option which enables debugging information when passed to . The same can be accomplished by the -g option, if you are using the “traditional” way for building your kernels (see for more information).
options SCHED_4BSD # 4BSD scheduler
The traditional scheduler for FreeBSD. Depending on your system's workload, you may gain performance by using the new ULE scheduler for FreeBSD that has been designed specially for SMP, but works just fine on UP systems too. If you wish to try it out, replace SCHED_4BSD with SCHED_ULE in your configuration file.
options INET # InterNETworking
Networking support. Leave this in, even if you do not plan to be connected to a network. Most programs require at least loopback networking (i.e., making network connections within your PC), so this is essentially mandatory.
options INET6 # IPv6 communications protocols
This enables the IPv6 communication protocols.
options FFS # Berkeley Fast Filesystem
This is the basic hard drive file system. Leave it in if you boot from the hard disk.
options SOFTUPDATES # Enable FFS Soft Updates support
This option enables Soft Updates in the kernel, this will help speed up write access on the disks. Even when this functionality is provided by the kernel, it must be turned on for specific disks. Review the output from to see if Soft Updates is enabled for your system disks. If you do not see the soft-updates option then you will need to activate it using the (for existing file systems) or (for new file systems) commands.
options UFS_ACL # Support for access control lists
This option, present only in FreeBSD 5.X, enables kernel support for access control lists. This relies on the use of extended attributes and . ACLs are enabled by default and should not be disabled in the kernel if they have been used previously on a file system, as this will remove the access control lists, changing the way files are protected in unpredictable ways.
options UFS_DIRHASH # Improve performance on big directories
This option includes functionality to speed up disk operations on large directories, at the expense of using additional memory. You would normally keep this for a large server, or interactive workstation, and remove it if you are using FreeBSD on a smaller system where memory is at a premium and disk access speed is less important, such as a firewall.
options MD_ROOT # MD is a potential root device
This option enables support for a memory backed virtual disk used as a root device.
options NFSCLIENT # Network Filesystem Client
options NFSSERVER # Network Filesystem Server
options NFS_ROOT # NFS usable as /, requires NFSCLIENT
The network file system. Unless you plan to mount partitions from a UNIX® file server over TCP/IP, you can comment these out.
options MSDOSFS # MSDOS Filesystem
The MS-DOS® file system. Unless you plan to mount a DOS formatted hard drive partition at boot time, you can safely comment this out. It will be automatically loaded the first time you mount a DOS partition, as described above. Also, the excellent emulators/mtools software allows you to access DOS floppies without having to mount and unmount them (and does not require MSDOSFS at all).
options CD9660 # ISO 9660 Filesystem
The ISO 9660 file system for CDROMs. Comment it out if you do not have a CDROM drive or only mount data CDs occasionally (since it will be dynamically loaded the first time you mount a data CD). Audio CDs do not need this file system.
options PROCFS # Process filesystem
The process file system. This is a “pretend” file system mounted on /proc which allows programs like to give you more information on what processes are running. In FreeBSD 5.X and above, use of PROCFS is not required under most circumstances, as most debugging and monitoring tools have been adapted to run without PROCFS: unlike in FreeBSD 4.X, new installations of FreeBSD 5.X will not mount the process file system by default. In addition, 6.X-CURRENT kernels making use of PROCFS must now also include support for PSEUDOFS:
options PSEUDOFS # Pseudo-filesystem framework
PSEUDOFS is not available in FreeBSD 4.X.
options GEOM_GPT # GUID Partition Tables.
This option brings the ability to have a large number of partitions on a single disk.
options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!]
Compatibility with 4.3BSD. Leave this in; some programs will act strangely if you comment this out.
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
This option is required on FreeBSD 5.X i386™ and Alpha systems to support applications compiled on older versions of FreeBSD that use older system call interfaces. It is recommended that this option be used on all i386 and Alpha systems that may run older applications; platforms that gained support only in 5.X, such as ia64 and Sparc64®, do not require this option.
options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI
This causes the kernel to pause for 15 seconds before probing each SCSI device in your system. If you only have IDE hard drives, you can ignore this, otherwise you will probably want to lower this number, perhaps to 5 seconds, to speed up booting. Of course, if you do this and FreeBSD has trouble recognizing your SCSI devices, you will have to raise it again.
options KTRACE # ktrace(1) support
This enables kernel process tracing, which is useful in debugging.
options SYSVSHM # SYSV-style shared memory
This option provides for System V shared memory. The most common use of this is the XSHM extension in X, which many graphics-intensive programs will automatically take advantage of for extra speed. If you use X, you will definitely want to include this.
options SYSVMSG # SYSV-style message queues
Support for System V messages. This option only adds a few hundred bytes to the kernel.
options SYSVSEM # SYSV-style semaphores
Support for System V semaphores. Less commonly used but only adds a few hundred bytes to the kernel.
Note: The -p option of the command will list any processes using each of these System V facilities.
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
Real-time extensions added in the 1993 POSIX®. Certain applications in the Ports Collection use these (such as StarOffice™).
options KBD_INSTALL_CDEV # install a CDEV entry in /dev
This option is related to the keyboard. It installs a CDEV entry in /dev.
options AHC_REG_PRETTY_PRINT # Print register bitfields in debug
# output. Adds ~128k to driver.
options AHD_REG_PRETTY_PRINT # Print register bitfields in debug
# output. Adds ~215k to driver.
This helps debugging by printing easier register definitions for reading.
options ADAPTIVE_GIANT # Giant mutex is adaptive.
Giant is the name of a mutual exclusion mechanism (a sleep mutex) that protects a large set of kernel resources. Today, this is an unacceptable performance bottleneck which is actively being replaced with locks that protect individual resources. The ADAPTIVE_GIANT option causes Giant to be included in the set of mutexes adaptively spun on. That is, when a thread wants to lock the Giant mutex, but it is already locked by a thread on another CPU, the first thread will keep running and wait for the lock to be released. Normally, the thread would instead go back to sleep and wait for its next chance to run. If you are not sure, leave this in.
device apic # I/O APIC
The apic device enables the use of the I/O APIC for interrupt delivery. The apic device can be used in both UP and SMP kernels, but is required for SMP kernels. Add options SMP to include support for multiple processors.
device isa
All PCs supported by FreeBSD have one of these. Do not remove this, even if you have no ISA slots. If you have an IBM PS/2 (Micro Channel Architecture) system, FreeBSD provides only limited support at this time. For more information about the MCA support, see /usr/src/sys/i386/conf/NOTES.
device eisa
Include this if you have an EISA motherboard. This enables auto-detection and configuration support for all devices on the EISA bus.
device pci
Include this if you have a PCI motherboard. This enables auto-detection of PCI cards and gatewaying from the PCI to ISA bus.
# Floppy drives
device fdc
This is the floppy drive controller.
# ATA and ATAPI devices
device ata
This driver supports all ATA and ATAPI devices. You only need one device ata line for the kernel to detect all PCI ATA/ATAPI devices on modern machines.
device atadisk # ATA disk drives
This is needed along with device ata for ATA disk drives.
device ataraid # ATA RAID drives
This is needed along with device ata for ATA RAID drives.
device atapicd # ATAPI CDROM drives
This is needed along with device ata for ATAPI CDROM drives.
device atapifd # ATAPI floppy drives
This is needed along with device ata for ATAPI floppy drives.
device atapist # ATAPI tape drives
This is needed along with device ata for ATAPI tape drives.
options ATA_STATIC_ID # Static device numbering
This makes the controller number static; without this, the device numbers are dynamically allocated.
# SCSI Controllers
device ahb # EISA AHA1742 family
device ahc # AHA2940 and onboard AIC7xxx devices
device ahd # AHA39320/29320 and onboard AIC79xx devices
device amd # AMD 53C974 (Teckram DC-390(T))
device isp # Qlogic family
device mpt # LSI-Logic MPT-Fusion
#device ncr # NCR/Symbios Logic
device sym # NCR/Symbios Logic (newer chipsets)
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 controllers. Comment out any you do not have in your system. If you have an IDE only system, you can remove these altogether.
# 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)
SCSI peripherals. Again, comment out any you do not have, or if you have only IDE hardware, you can remove them completely.
Note: The USB driver and a few other drivers use the SCSI subsystem even though they are not real SCSI devices. Therefore make sure not to remove SCSI support, if any such drivers are included in the kernel configuration.
# RAID controllers interfaced to the SCSI subsystem
device amr # AMI MegaRAID
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
device hptmv # Highpoint RocketRAID 182x
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
device mlx # Mylex DAC960 family
device pst # Promise Supertrak SX6000
device twe # 3ware ATA RAID
Supported RAID controllers. If you do not have any of these, you can comment them out or remove them.
# atkbdc0 controls both the keyboard and the PS/2 mouse
device atkbdc # AT keyboard controller
The keyboard controller (atkbdc) provides I/O services for the AT keyboard and PS/2 style pointing devices. This controller is required by the keyboard driver (atkbd) and the PS/2 pointing device driver (psm).
device atkbd # AT keyboard
The atkbd driver, together with atkbdc controller, provides access to the AT 84 keyboard or the AT enhanced keyboard which is connected to the AT keyboard controller.
device psm # PS/2 mouse
Use this device if your mouse plugs into the PS/2 mouse port.
device vga # VGA video card driver
The video card driver.
# splash screen/screen saver
device splash # Splash screen and screen saver support
Splash screen at start up! Screen savers require this too. Use the line pseudo-device splash with FreeBSD 4.X.
# syscons is the default console driver, resembling an SCO console
device sc
sc is the default console driver and resembles a SCO console. Since most full-screen programs access the console through a terminal database library like termcap, it should not matter whether you use this or vt, the VT220 compatible console driver. When you log in, set your TERM variable to scoansi if full-screen programs have trouble running under this console.
# Enable this for the pcvt (VT220 compatible) console driver
#device vt
#options XSERVER # support for X server on a vt console
#options FAT_CURSOR # start with block cursor
This is a VT220-compatible console driver, backward compatible to VT100/102. It works well on some laptops which have hardware incompatibilities with sc. Also set your TERM variable to vt100 or vt220 when you log in. This driver might also prove useful when connecting to a large number of different machines over the network, where termcap or terminfo entries for the sc device are often not available -- vt100 should be available on virtually any platform.
device agp
Include this if you have an AGP card in the system. This will enable support for AGP, and AGP GART for boards which have these features.
# Floating point support - do not disable.
device npx
npx is the interface to the floating point math unit in FreeBSD, which is either the hardware co-processor or the software math emulator. This is not optional.
# Power management support (see NOTES for more options)
#device apm
Advanced Power Management support. Useful for laptops, although in FreeBSD 5.X and above this is disabled in GENERIC by default.
# Add suspend/resume support for the i8254.
device pmtimer
Timer device driver for power management events, such as APM and ACPI.
# 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
PCMCIA support. You want this if you are using a laptop.
# Serial (COM) ports
device sio # 8250, 16[45]50 based serial ports
These are the serial ports referred to as COM ports in the MS-DOS/Windows® world.
Note: If you have an internal modem on COM4 and a serial port at COM2, you will have to change the IRQ of the modem to 2 (for obscure technical reasons, IRQ2 = IRQ 9) in order to access it from FreeBSD. If you have a multiport serial card, check the manual page for for more information on the proper values to add to your /boot/device.hints. Some video cards (notably those based on S3 chips) use IO addresses in the form of 0x*2e8, and since many cheap serial cards do not fully decode the 16-bit IO address space, they clash with these cards making the COM4 port practically unavailable.
Each serial port is required to have a unique IRQ (unless you are using one of the multiport cards where shared interrupts are supported), so the default IRQs for COM3 and COM4 cannot be used.
# Parallel port
device ppc
This is the ISA-bus parallel port interface.
device ppbus # Parallel port bus (required)
Provides support for the parallel port bus.
device lpt # Printer
Support for parallel port printers.
Note: All three of the above are required to enable parallel printer support.
device plip # TCP/IP over parallel
This is the driver for the parallel network interface.
device ppi # Parallel port interface device
The general-purpose I/O (“geek port”) + IEEE1284 I/O.
#device vpo # Requires scbus and da
This is for an Iomega Zip drive. It requires scbus and da support. Best performance is achieved with ports in EPP 1.9 mode.
#device puc
Uncomment this device if you have a “dumb” serial or parallel PCI card that is supported by the glue driver.
# PCI Ethernet NICs.
device de # DEC/Intel DC21x4x (“Tulip”)
device em # Intel PRO/1000 adapter Gigabit Ethernet Card
device ixgb # Intel PRO/10GbE Ethernet Card
device txp # 3Com 3cR990 (“Typhoon”)
device vx # 3Com 3c590, 3c595 (“Vortex”)
Various PCI network card drivers. Comment out or remove any of these not present in your system.
# 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
MII bus support is required for some PCI 10/100 Ethernet NICs, namely those which use MII-compliant transceivers or implement transceiver control interfaces that operate like an MII. Adding device miibus to the kernel config pulls in support for the generic miibus API and all of the PHY drivers, including a generic one for PHYs that are not specifically handled by an individual driver.
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)
device lge # Level 1 LXT1001 gigabit ethernet
device nge # NatSemi DP83820 gigabit ethernet
device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc')
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
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
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”)
Drivers that use the MII bus controller code.
# 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.
device lnc # NE2100, NE32-VL Lance Ethernet cards
device sn # SMC's 9000 series of Ethernet chips
device xe # Xircom pccard Ethernet
# ISA devices that use the old ISA shims
#device le
ISA Ethernet drivers. See /usr/src/sys/i386/conf/NOTES for details of which cards are supported by which driver.
# Wireless NIC cards
device wlan # 802.11 support
device an # Aironet 4500/4800 802.11 wireless NICs.
device awi # BayStack 660 and others
device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs.
#device wl # Older non 802.11 Wavelan wireless NIC.
Support for various wireless cards.
# Pseudo devices
device loop # Network loopback
This is the generic loopback device for TCP/IP. If you telnet or FTP to localhost (a.k.a. 127.0.0.1) it will come back at you through this device. This is mandatory. Under FreeBSD 4.X you have to use the line pseudo-device loop.
device mem # Memory and kernel memory devices
The system memory devices.
device io # I/O device
This option allows a process to gain I/O privileges. This is useful in order to write userland programs that can handle hardware directly. This is required to run the X Window system.
device random # Entropy device
Cryptographically secure random number generator.
device ether # Ethernet support
ether is only needed if you have an Ethernet card. It includes generic Ethernet protocol code. Under FreeBSD 4.X use the line pseudo-device ether.
device sl # Kernel SLIP
sl is for SLIP support. This has been almost entirely supplanted by PPP, which is easier to set up, better suited for modem-to-modem connection, and more powerful. With FreeBSD 4.X use the line pseudo-device sl.
device ppp # Kernel PPP
This is for kernel PPP support for dial-up connections. There is also a version of PPP implemented as a userland application that uses tun and offers more flexibility and features such as demand dialing. With FreeBSD 4.X use the line pseudo-device ppp.
device tun # Packet tunnel.
This is used by the userland PPP software. See the section of this book for more information. With FreeBSD 4.X use the line pseudo-device tun.
device pty # Pseudo-ttys (telnet etc)
This is a “pseudo-terminal” or simulated login port. It is used by incoming telnet and rlogin sessions, xterm, and some other applications such as Emacs.
Note: Under FreeBSD 4.X, you have to use the line pseudo-device pty number. The number after pty indicates the number of ptys to create. If you need more than the default of 16 simultaneous xterm windows and/or remote logins, be sure to increase this number accordingly, up to a maximum of 256.
device md # Memory “disks”
Memory disk pseudo-devices. With FreeBSD 4.X use the line pseudo-device md.
device gif # IPv6 and IPv4 tunneling
This implements IPv6 over IPv4 tunneling, IPv4 over IPv6 tunneling, IPv4 over IPv4 tunneling, and IPv6 over IPv6 tunneling. Beginning with FreeBSD 4.4 the gif device is “auto-cloning”, and you should use the line pseudo-device gif. Earlier versions of FreeBSD 4.X require a number, for example pseudo-device gif 4.
device faith # IPv6-to-IPv4 relaying (translation)
This pseudo-device captures packets that are sent to it and diverts them to the IPv4/IPv6 translation daemon. With FreeBSD 4.X use the line pseudo-device faith 1.
# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device bpf # Berkeley packet filter
This is the Berkeley Packet Filter. This pseudo-device allows network interfaces to be placed in promiscuous mode, capturing every packet on a broadcast network (e.g., an Ethernet). These packets can be captured to disk and or examined with the program. With FreeBSD 4.X use the line pseudo-device bpf.
Note: The device is also used by to obtain the IP address of the default router (gateway) and so on. If you use DHCP, leave this uncommented.
# USB support
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 urio # Diamond Rio 500 MP3 player
device uscanner # Scanners
# USB Ethernet, requires mii
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
Support for various USB devices.
# FireWire support
device firewire # FireWire bus code
device sbp # SCSI over FireWire (Requires scbus and da)
device fwe # Ethernet over FireWire (non-standard!)
Support for various Firewire devices.
For more information and additional devices supported by FreeBSD, see /usr/src/sys/i386/conf/NOTES.
Large memory configuration machines require access to more than the 4 gigabyte limit on User+Kernel Virtual Address ( interface will cause data corruption in a manual page. The manual page contains up-to-date information on FreeBSD's
If you are running FreeBSD 5.0 or later you can safely skip this section. These versions use devfs(5) to allocate device nodes transparently for the user.
Almost every device in the kernel has a corresponding “node” entry in the /dev directory. These nodes look like regular files, but are actually special entries into the kernel which programs use to access the device. The shell script /dev/MAKEDEV, which is executed when you first install the operating system, creates nearly all of the device nodes supported. However, it does not create all of them, so when you add support for a new device, it pays to make sure that the appropriate entries are in this directory, and if not, add them. Here is a simple example:
Suppose you add the IDE CD-ROM support to the kernel. The line to add is:
device acd0
This means that you should look for some entries that start with acd0 in the /dev directory, possibly
followed by a letter, such as c, or preceded by the
letter r, which means a “raw” device. It turns out that
those files are not there, so you must change to the
