Download
1 / 53
530 likes | 675 Views
System Devices. Chapter 7. Understand internal system device interconnections. Understand device configuration and access from the hardware perspective. Understand device configuration and access from the software perspective.
E N D
System Devices Chapter 7
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. Chapter Goals
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. System Devices
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. Generic Architecture
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 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. 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). Windows 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. 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. 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. UNIX Device Terminology
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. Problems with the UNIX view
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 ioctls as standard, and specific variants of UNIX define several other “proprietary” ioctls. • Stty, eject, offline IOCTLs
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. 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. Generic Device I/O
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. System Configurations
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. UNIX 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. 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. 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. Solaris 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. 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. UNIX Device Tree
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. 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 sddevice. • 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. 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. 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). System V 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. 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? 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. BSD Device Names
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. 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. 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 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. PROM 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. Hardware Device Access
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. Reconfiguring Device Information
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. Adding Windows 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. Adding Linux 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. Adding BSD Devices
Each line begins with a keyword • machine - Define the machine type i386cpu • cpu - Define the CPU type i686_cpuident • ident - Define the name of the kernel my_kernelmaxusers • maxusers - Define the kernel table sizes maxusers=16options • options - Define compile-time options options symbol=valueconfig • config - Define the root and swap partitions config my_kernel root on wd0controller • 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) 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. 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 sysctla will cause the system to list all of the tunable kernel parameters. Adding BSD 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. Adding Solaris Devices
