Ch07 system administration
- 2. Chapter Goals Understand internal system device interconnections. Understand device configuration and access from the hardware perspective. Understand device configuration and access from the software perspective. Understand how to view the system’s copy of the device information. Understand device naming schemes used by various operating systems. Understand how to add a device to an operating system, and rebuild the kernel.
- 3. System Devices In order to manage the devices on the system, the sysadmin must have some concept of system architecture – the interconnection of devices on the system. A knowledge of how operating systems deal with devices is also good background information for the sysadmin. This chapter examines some of the terminology associated with system devices, and some generic information about device/operating system interaction.
- 5. Generic Architecture There are two basic types of buses that we will examine: Serial bus – a bus which contains a single pair of wires for unidirectional data transmission. COM ports, and network connections are typical examples of serial bus devices. Parallel bus – a bus which contains multiple wires for high-speed bi-directional data transfers. Disk drives, tape drives, and graphics cards are typical examples of parallel bus devices.
- 6. Device Terminology Parallel Bus Interfaces and Bus Standards PCMCIA Bus – 16 bits wide, 4/8MHz, 4/8 megabyte/second EISA Bus – 16 bits wide, 8 MHz, 33 megabyte/second PCI Bus – 32/64 bit wide, 33/66 MHz, 264 megabyte/second Sbus – 32/64 bit wide, 25 MHz, 168 megabyte/second AGP Bus – 32 bit wide, 66 MHz, 2 gigabytes/second Parallel Ports – 8 bits wide Serial Bus Interfaces COM Ports – RS323, RS422, RS423, 100Kbit/second USB Bus – up to 15 megabytes/second Firewire – hundreds of megabytes/second
- 7. Windows Device Terminology Windows defines devices in terms of an interrupt level (IRQ), a memory range, and a group of device registers (I/O range). All device interactions between Windows and a specific device are handled via a device driver. The device driver requires knowledge of the IRQ, memory range, and I/O range of the device. The kernel contains a table of all devices connected to the system. This table contains the appropriate values for these “variables” for each device.
- 8. Windows Device Terminology Interrupt Request (IRQ) A signal line that is used to signify that a device requires service. Memory Range The memory space occupied by the device interface. I/O Range The memory space designated for the device registers. Plug-and-play A method to allow the system to auto-configure the board settings (IRQ, I/O range, Memory range).
- 9. UNIX Device Terminology UNIX “thinks” that everything in the universe is a file. UNIX devices are nothing more than special files. The special files have attributes that allow the kernel to load the correct device driver in order to service I/O requests.
- 10. UNIX Device Terminology Information displayed by the ls command for a typical text file includes: Size in blocks: Number of blocks this file occupies on the disk. Permissions: Read, write, and execute bits for the owner, group, and world. Link count: Number of hard and soft links to this file. Owner: Owner of this file. Group: Group owner of this file. Size: Size of this file in bytes. Modify date: Modify date for the file. File name: Name of this file.
- 11. UNIX Device Terminology Information displayed by the ls command for a device special file includes: Size in blocks: Number of disk blocks this file occupies. Access mode: Single character that determines the access mode of the device. Permissions: Read/write/execute bits for the owner of the file, the group owner of the file, and the rest of the world. Reference count: Count of hard and soft links to this file. Owner: User ID of the user that “owns” this device. Group: Group ID of the group that owns this device. Major: This field identifies the “class” of device with which you are dealing. The number in this field is used as an index to a table of device types. Minor: This field is used as a secondary index to a table of devices within a specific device class. Modify date: Date the device was last written. File name: “Name” of the device.
- 12. Problems with the UNIX view Whereas UNIX likes to view everything as a file, some device operations defy the designer’s ability to connect file operations to device operations. It is pretty easy to envision read, write, seek, and rewind in terms of file operations. But how can you describe an operation such as setting the speed of a serial port in terms of file operations? Similarly, how could the operation of ejecting a tape, floppy diskette, or CD-ROM be described in terms of a file operation? These operations defy all attempts to describe them in terms of a file operation; therefore, another mechanism was introduced to enable these actions.
- 13. IOCTLs Input/output control functions (IOCTL) are the mechanisms that allow UNIX to implement the odd operations that cannot be described in the scope of file operations. The ioctl routines are small programs or functions specifically crafted to achieve a single operation. UNIX defines several ioctl s as standard, and specific variants of UNIX define several other “proprietary” ioctl s. Stty, eject, offline
- 14. Generic Device I/O When a device asserts an interrupt: The system reads the IRQ lines to determine what type of device handler (driver) to invoke. The device driver scans the I/O registers of all devices of that type to determine which unit has the interrupt bit set. The device driver uses other information in the device registers to perform an I/O operation (read/write/…). When the I/O operation completes, the device driver return control to the kernel.
- 15. Generic Device I/O When a system requires I/O: The system invokes the device driver and passes it a structure that defines the requested operation. The device driver uses the information in the kernel tables to contact the appropriate device. The device driver sets/clears bits in the device registers to cause the device to perform an I/O operation (read/write/…). Unless this is a blocking operation, the device driver returns control to the kernel, and the operation is performed (somewhat) asynchronously.
- 16. System Configurations Because the kernel contains tables that map the devices to specific drivers, it should be possible for us to view this information. If we want to troubleshoot a device we want to see that it is “where we thought it should be” We can use this information to build an inventory of what is on the system. This makes adding a new device a little bit easier.
- 19. UNIX Device Tree As mentioned in the chapter on booting, many systems use code in the PROM monitor to build a device information tree. This device tree shows the interconnection of system components, and contains address/memory/IO information for each device.
- 20. Solaris Device Tree Under System V, the physical device interface to the nodes on the device information tree lies in the /devices directory (Solaris) or the /hw directory (IRIX). This directory contains subdirectories that store device-special files for audio devices, floppy disk drives, the eeprom , pseudo devices, bus adapters, serial port devices, and other system devices. Within each subdirectory of the devices directory there are more entries, which may be special-device files or directories containing special-device files. The directory hierarchy simplifies the task of locating a specific device by grouping device entries for that type of device in a single directory.
- 23. Solaris Device Tree The Solaris prtconf utility allows the administrator to print the system configuration to a terminal or line printer. This utility provides a list of devices and drivers loaded in the system. Indenting child node information with respect to parent nodes in the prtconf output preserves the device information tree data. When used with the -p flag, prtconf will display the OpenBoot prom information about the devices. The -v flag tells prtconf to display the output in verbose format.
- 25. Solaris Device Tree The Solaris sysdef utility also allows the administrator to examine system configuration information. The sysdef utility provides a list of devices defined on the system and loadable driver modules, as well as the state of many tunable kernel variables. Indenting child node information with respect to parent nodes in the sysdef output preserves the device information tree information.
- 27. UNIX Device Tree Unfortunately, the utilities to display the device tree vary by operating system. All operating systems have a way to view the information, but this requires that the sysadmin needs to be familiar with multiple commands to perform one operation. Some third party tools work with multiple versions of UNIX operating systems The sysinfo command is one such utility.
- 28. UNIX Device Tree
- 29. UNIX Device Tree Linux (and to some extent Solaris) make use of the /proc file system to manage some portions of the device information tree. The Linux developers have put a lot of thought and time into the /proc file system and the capabilities provided by this structure. Under the /proc file system is one of the interfaces to the system devices. The device information tree can be seen by using the ls command to view the /proc file system.
- 30. Device Names Under Windows, devices have fairly simple names: COM ports – communication ports LPT – the line printer port. Disk Tape SCSI Sound Display In order to determine the names of the devices on the system, simply use the device manager to display the device list.
- 31. Device Names Unfortunately, under UNIX, device names can be very difficult to figure out. Most devices on a UNIX system are named with an acronym derived from the device type. For instance, on many UNIX variants, an SCSI disk drive is an sd device. On other UNIX variants, a disk may be known as a dsk device, an hd device, and in one case, a dad device. An SCSI tape drive may be an st device on one system, but this same tape drive could be an rmt device, or a ct device, on another system.
- 32. System V Device Names System V provides an easy-to-use, easy-to-remember method of accessing devices that does not require the memorization of several eight-digit hexadecimal addresses. System V allows multiple names for each device on the system. The operating system’s link to the physical device is through a file in the /hw or /devices directory. However, many System V operating systems also include aliases for these /hw and /devices entries. Under Solaris, such alias entries reside in the /dev directory, and are symbolically linked to the entries in the /devices directory.
- 33. System V Device Names The Solaris /dev/dsk directory contains entries with names such as /dev/dsk/c0t3d0s0 . This form of device name is often referred to as the “alphabet soup” designator for the device. These logical names for devices are much easier for most users to remember than names such as /devices/sbus@1,f8000000/esp@ 0,800000/sd@3,0:a,raw . A Solaris alphabet soup name for a device consists of four fields: Controller (CN), Target (TN), Device (DN), and Slice (SN).
- 34. BSD Device Names The device-naming scheme used by early BSD UNIX variants is quite different from the System V naming. Most of the device acronyms are derived from the type of device, and/or the manufacturer of the device. For example, an SCSI disk device might be called sd#P , where sd is an “scsi disk,” # refers to the SCSI target address, and P refers to a file system partition on that drive. For example, /dev/sd3a on a SunOS 4.1.3 system refers to the “a” partition of the disk connected to the on-board SCSI controller at address 3. Recent versions of the BSD software (FreeBSD, BSDI, NetBSD) have stayed with this simple device-naming scheme.
- 35. BSD Device Names BSD UNIX uses pretty simple acronyms to name some of the devices: sd is an scsi disk, st is an SCSI tape, tty is a tty device (serial port), kb is a keyboard, eth (or ec ) is an Ethernet controller, and so on. Although these names may be easy to derive, there are problems with this scheme. Consider, for example, a system with an SCSI controller, a system console device, and a scanner device. Which device is /dev/sc0 ?
- 36. BSD Device Names Although parts of Linux are System V-ish, the device names are more BSD-ish. Under Linux, an IDE disk drive is /dev/hda (hard disk A), whereas an SCSI disk is /dev/sda ( scsi disk A). Other system device acronyms under Linux may also vary from the scheme used by most BSD operating systems . NOTE: Substitute appropriate unit numbers for the # symbols in the table. Here, W = controller, X = SCSI ID, Y = device ID, and Z = Partition.slice. For Linux: L = Unit “letter” and P = partition letter or number.
- 38. PROM Device Access Some hardware architectures allow considerable access to the device tree from the PROM monitor. Intel architectures are generally limited due to BIOS limitations. SPARC, PA/RISC, and PowerPC architectures offer very good availability.
- 39. PROM Device Access The SPARC OpenBoot monitor refers to devices by their points of connection to the system. The operating system refers to devices by mnemonic names and device-special files. Most of the device names that system administrators deal with are actually aliases that point to some physical device on the system.
- 40. PROM Device Access For example, the root file system may reside on a disk referred to as either /dev/dsk/c0t3d0s0 or sd3a by the administrator. This same disk is known to the OpenBoot monitor as disk3 , /devices/pci@1f,4000/scsi@3/sd@3,0:a /sbus@1,f8000000/esp@0,4000/sd@3,0:a To list the hardware on a Solaris box, use the PROM monitor’s show-devs command
- 41. PROM Device Access The show-devs command will return output formatted as follows: name: A name is a text string that generally has a mnemonic value. For example, sd represents an SCSI disk. Many controller names use some portion of the manufacturer’s name or model number. @: The “at” symbol must precede the address parameter. address: The address is a hexadecimal numeral string representing the physical address of the device on the system. The address is usually in the following form: hex_number,hex_number . “ :”: A colon must precede the arguments parameter. arguments: The arguments constitute a text string whose format depends on the device. The arguments may be used to pass additional information to the device’s driver software.
- 42. Hardware Device Access Examining the physical address of a device allows the system administrator to determine the point of connection for that device. To determine the point of connection for the disk3 device, simply break down the physical address /pci@1f,0/pci@1,1/ide@3/dad@0,0:g into the following components. /pci@ - Device is connected to a PCI adapter. 1f,0 - An address on the on-board bus. pci@ - A pci interface is the on-board pci adapter. 1,1 - A pci slot number and an address offset within that slot. This means that the pci device is in pci slot 1 with a hexadecimal address offset of 1 from the parent node (main system bus) address . ide@ - An IDE adapter connected to the PCI. 3 - The IDE adapter’s address offset from the pci bus adapter. dad@ - Device in question is an IDE disk. 0,0:g - Denotes IDE target 0, logical unit number 0, partition g of the disk.
- 43. Reconfiguring Device Information Sometimes when a new peripheral is installed in a system it becomes necessary to reconfigure other peripherals. For instance, it may be necessary to move an adapter card from one slot to another slot in the system to allow the installation of a new adapter card. Because the device information tree contains information concerning the slot number of each device on the system buses, the device information tree must be rebuilt whenever devices are moved or new devices are installed on the system. Generally, you want to minimize changing device names, as you may have to manually edit system files to reflect these changes.
- 44. Adding Windows Devices Under Windows, the plug-n-play software generally handles installation of new devices. The plug-n-play code finds a new device on the system bus, and probes the device to determine what it is. If the device supports plug-n-play, it tells the system what type of device, and what driver it wants. The OS loads the driver from the generic pool of drivers, or asks you for media to load from.
- 45. Adding Linux Devices The generic “menu” for adding a new device to a Linux system includes the following. Obtain source code for your kernel and place it in /usr/src/linux. Build new kernel: Use the Linux kernel configuration tools to configure a new kernel, and then compile the new kernel. Install new kernel: Copy the recently compiled kernel to the /boot directory and inform the boot manager of its presence. Reboot new kernel: Shut the system down and hopefully boot the new kernel. NOTE: If your kernel uses loadable kernel modules, you may be able to add a device drivers on the fly.
- 46. Adding BSD Devices Creating the “menu” for adding a new device to a BSD system is similar to the procedure for adding a device to a Linux system. Obtain source code for your kernel and place it in /usr/src/sys . Build the new kernel; that is, create a new configuration file. This is the difficult part. The config file is a series of directives that tell the config program what you want it to do.
- 47. Adding BSD Devices Each line begins with a keyword machine - Define the machine type i386 cpu cpu - Define the CPU type i686_cpu ident ident - Define the name of the kernel my_kernel maxusers maxusers - Define the kernel table sizes maxusers=16 options options - Define compile-time options options symbol=value config config - Define the root and swap partitions config my_kernel root on wd0 controller controller - Define the mass storage controllers controller wd0 ad isa? Port “IO_WDI” bio irq 14 disk - Define a disk connected to a controller disk wd0 at wdc0 drive 0 tape - Define a tape connected to a controller tape wt0 at wdc0 drive 4 device - Define a device that has no controller device sc0 at isa? Tty (system console device) pseudo-device - Define a pseudo device pseudo-device loop (network loopback device)
- 48. Adding BSD Devices Once you have configured all of the devices, build the kernel. 1. Run the config command to build the kernel compilation repository. The configuration file should be located in /sys/arch/conf , and the config command will create the directory /sys/compile/kernel_name (where kernel_name is the name of your new kernel configuration). Once this completes, change the directory to the compilation directory, and run the command make depend , followed by the command make .
- 49. Adding BSD Devices 2. Install new kernel: Copy the recently compiled kernel to the root directory. It is best to not write over the running kernel. Therefore, first copy the running kernel to something like /vmunix.ok , and then copy the new kernel to /vmunix . 3. Reboot new kernel: Shut the system down and hopefully boot the new kernel. It is possible to tune the BSD kernel using the sysctl command. Invoking sysctl a will cause the system to list all of the tunable kernel parameters .
- 50. Adding Solaris Devices Solaris provides several methods of rebuilding the device information tree. Two of these methods require a system reboot. The third method allows the operator to reconfigure devices “on the fly.” boot -r : This command tells the OpenBoot monitor to reconfigure the device information tree before starting the operating system. touch /reconfigure; reboot : The Solaris start-up code looks in the root directory for the /reconfigure file. If this file exists, Solaris will rebuild the device information tree as part of the boot process.
- 51. Adding Solaris Devices A more dangerous way of reconfiguring the system on the fly is to execute the drvconfig , disks , tapes , and devlinks commands. These four commands cause the system to probe for new disk and tape devices, and add them to the device information tree while the system is up and running. Although these commands are available and perform the task, it is always best to use the boot -r command to let the system find and install the devices at reboot time. In addition to rebuilding the device information tree, you can edit the /etc/system file to supply configuration options to the kernel at boot time.
- 52. Summary This chapter examined how devices on systems are named and how they are addressed. Several examples detail the relationship between device-special files, logical device names, device aliases, physical device names, and addresses of the devices. The examples also show how to track down the device physical address information for several typical device aliases. Many PROM monitors also give the operator access to system devices. This chapter examined some of the PROM monitor commands available to examine/configure system devices. Example output shows how to identify the devices and driver modules loaded on a system, how to use this information to determine where to install new devices on the system, and how to force the system to reconfigure the device information when devices are added to or removed from the system.
- 53. Summary The administrator should understand internal system device interconnections. The administrator should understand device configuration and access from the hardware perspective. The administrator should understand device configuration and access from the software perspective. The administrator should understand how to view the system’s copy of the device information. The administrator should understand device naming schemes used by various operating systems. The administrator should understand how to add a device to an operating system, and rebuild the kernel.
Editor's Notes
- #5: Internally, the system may contain multiple system busses. The memory and I/O busses may be combined, or there may be multiple busses dedicated to individual tasks. The sysadmin cannot do much with these busses, as they are generally etched on a circuit board. The I/O busses are the ones that we are interested in, as quite often, the sysadmin needs to install/troubleshoot/remove devices from these busses. Access to these busses is typically provided via connectors on the system motherboard. Sometimes these connectors are used to “spawn” another bus (such as the ISA bus, the PCI bus, the Sbus, …), and sometimes the connectors are end-device connection points (COM ports, Parallel ports, …).
- #9: Each device interface has the ability to interrupt the processor. The kernel contains a table that maps interrupt levels to device driver routines. When a device asserts it’s IRQ line, the system reads the IRQ level from the bus, and consults the table to determine which service routine to invoke. NOTE: That multiple devices within the same device class may share an IRQ line. For example, multiple Ethernet interfaces may share the same IRQ. In this case, the driver must poll all Ethernet devices in order to determine which one asserted the interrupt. Allowing different types of devices to share an interrupt request level will probably lead to problems! The device interface typically includes some command/control/status registers. These registers are bus interfaces to the device. The device driver needs to read/write values from/to these registers to make the device perform the necessary I/O operation, and to check the status of the device. The device may contain it’s own memory. This memory is typically mapped to system address space such that processor may access the memory to read/write data from/to the device.
- #12: if you have used “block mode” operations to transfer a “block” of data per reference (b), or character mode operations to transfer a single character of data at a time (c). Block mode operations typically involve direct memory access (DMA) operations.
- #17: The system input/output devices are attached to a set of interconnected buses. On many systems, the PROM monitor recognizes these interconnected buses and respective devices as a tree of nodes. At the root of the tree is a node that describes the entire system. The leaf (child) nodes are typically indented (with respect to their parent node) to show the hierarchical relationship between nodes. Nodes on the device information tree that have children generally represent system buses and the associated controllers on the buses. Each parent node is allocated a physical address space, and a major device number that distinguishes the devices on this node from one another. Each child of a parent node is allocated a minor device number, and a physical address within the parent node’s address space. The physical address of nodes is generally assigned in relation to the device’s physical characteristics, or the bus slot in which the controller is installed. This is done in an attempt to keep device addresses from changing as systems are upgraded and new devices are installed on the system. Each device node on the device information tree can have the following attributes. Properties or data structures that describe the node and associated devices. Methods or software procedures used to access the devices. Children (devices or other nodes) that are attached to the node and lie directly below it in the tree. A parent, or the node that lies directly above the current node in the device tree.
- #18: Under Windows, the device information tree is available under the operating system’s system control panel. The system control panel contains a link to the device manager. As shown the device manager provides a graphical representation of the available system devices. The display can be set to illustrate the devices by type, devices by connection, resources by type, and resources by connection. This allows the operator to view device interconnections and device resource utilization in several formats.
- #21: TIP: A simple method of identifying the address of any device on the system is to use the command ls –lsaR /devices/* The output of this command will list the device-special files for all devices on the system.
- #33: NOTE: Under Solaris, disk drives are the only devices that use alphabet soup designators. Other System V Release IV operating systems may use similar designators for tape drives and other system devices. Under HP/UX and IRIX, the /hw directory contains the device-special files. There are links from /dev/dsk to entries in /hw/disk . Under IRIX the disk name contains three portions. For example, /dev/dsk/dks0d1s0 is the IRIX disk drive unit 1, partition 0. The first s0 is the SCSI bus instance, the d1 is the disk unit number, and the second s0 is the disk partition of the specific disk. Many of the IRIX device names are more BSD-ish than they are System V-ish. The subdirectories within /hw are named for the type of device. Here, input , cpu , disk , scsi , net , and ttys are a few of the device directories available under IRIX.
- #34: CN represents controller number N. This refers to the logical controller number of the device interface. A system with a single SCSI interface would have devices connected to controller c0. A system with two SCSI interfaces may have SCSI devices connected to both the c0 and the c1 SCSI interfaces. TN represents the target number. This is the SCSI target ID (or SCSI address) of a device connected to the controller. DN represents the unit number of the device connected to target controller TN, which is in turn connected to bus controller CN. Some peripherals allow the connection of several devices to a single target controller on the SCSI bus. The device-naming scheme uses the DN field of the device name to refer to these child devices. A typical ESDI disk controller may connect to the SCSI bus as target 2. The ESDI controller may in turn allow the connection of two disk drives. These disk drives may be referred to as /dev/dsk/c0t2d0s2 and /dev/dsk/c0t2d1s2 . SN represents the slice or partition number of the device. See Chapter 9 for more information on disk slices and partitions. System V allows multiple names for each device on the system. As discussed in the section on device-special files, the operating system’s link to the physical device is through a file in the /hw or /devices directory. However, many System V operating systems also include aliases for these /hw and /devices entries. Under Solaris, such alias entries reside in the /dev directory, and are symbolically linked to the entries in the /devices directory. For example, the Solaris /dev/dsk directory contains entries with names such as /dev/dsk/c0t3d0s0 . This form of device name is often referred to as the “alphabet soup” designator for the device. These logical names for devices are much easier for most users to remember than names such as /devices/sbus@1,f8000000/esp@ 0,800000/sd@3,0:a,raw . A Solaris alphabet soup name for a device consists of four fields: Controller (CN), Target (TN), Device (DN), and Slice (SN). The following are descriptions of these fields. Under HP/UX and IRIX, the /hw directory contains the device-special files. There are links from /dev/dsk to entries in /hw/disk . Under IRIX the disk name contains three portions. For example, /dev/dsk/dks0d1s0 is the IRIX disk drive unit 1, partition 0. The first s0 is the SCSI bus instance, the d1 is the disk unit number, and the second s0 is the disk partition of the specific disk. Many of the IRIX device names are more BSD-ish than they are System V-ish. The subdirectories within /hw are named for the type of device. Here, input , cpu , disk , scsi , net , and ttys are a few of the device directories available under IRIX.
- #46: The generic steps required to build a new linux kernel: Change directory to the Linux source directory ( /usr/src/linux ). Invoke the command make xconfig . This will bring up an X11-based window that walks you through the configuration process. If you are not running X11 you can use make menuconfig to open a text-window-based configuration tool. It is important to know what hardware constitutes your system, and what hardware you are adding. You need this information so that you build a kernel that supports the right devices. Once you have selected all of the drivers to be included in the kernel, you exit the xconfig application and type the following commands: make dep make bzImage make modules make modules-install This set of steps will check for all of the build dependencies (include files, and libraries), build the kernel, build the loadable modules, and install the modules in the /lib/modules directory. Once these steps are completed, the kernel needs to be copied into the boot partition using the following. cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-“version” Then you edit the lilo.conf file and add the relevant information such that you can boot this new kernel. See Chapter 5 for more information on the lilo.conf file. Once the lilo.conf file has been updated, run the command /sbin/lilo to cause lilo to update the system tables. When this completes, you need to shut the system down and boot the new kernel. The new kernel may be tuned by making changes to the content of the files in /proc . For example, you can change the number of open files per process by changing the value in the file /proc/sys/fs/file-max . Kernel tuning is explored in Chapter 24.
- #49: Under BSD operating systems, the names can be difficult to divine. Few “standards” exist to assist you in naming a device. There are usually controllers named isa0 (ISA bus), pnp0 (Plug and Play), eisa0 (EISA bus), and pci0 (PCI bus). The console subsystem consists of a controller named atkbdco (AT keyboard controller), with devices named atkbd (AT keyboard), a psm0 (PS mouse), and a vga0 (video display). Floppy controllers are fdc devices, and floppy diskette drives are fd devices. The IDE controllers are named wdc0 and wdc1 , each of which can support two wd devices (disks). A CD-ROM drive is an acd0 device. For other devices, read the on-line documentation that comes with the specific BSD OS for more information on naming the devices.
- #51: Whenever a device is added or removed, the system should be restarted with the boot -r command. This forces the operating system to rebuild the device information tree and load the correct drivers.