Ch07

System Devices

Chapter 7

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.

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.

Generic System Architecture

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.

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

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.

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).

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.

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.

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.

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 ioctls as standard, and specific

variants of UNIX define several other “proprietary” ioctls. • Stty, eject, offline

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.

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.

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.

Windows Device Tree

Windows Device Tree

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.

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.

Solaris Device Tree

Solaris Device Tree

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

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 out put preserves the device information tree information.

Solaris Device Tree

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.

UNIX Device Tree

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.

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.

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.

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.

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).

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.

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.

Device Linux (/dev/) Solaris (/dev/) BSD (/dev/)

Disk (SCSI/ RAID)

sdLP; ida/cWdXpZ

dsk/cWtXdYsZ; sd#{a-h}

da#

Disk (IDE) /dev/hdLP dsk/cWtXdYsZ; dad#{a-h}

wd#

Tape st# rmt/# st#

Ethernet eth# hme#; eri# le#

Video Display

fb fbs/ffb vga#

Keyboard keyboard kbd atkbd#

Mouse mouse mouse psm#

Diskette floppy diskette fd#

CD-ROM scd# dsk/cWt6dYsZ; cdrom

acd#

Console Port (serial)

cons; ttyS# term/a ttyd#

Serial Port tty# term/a tty#

Printer Port Ecppp0; Bppp0

bpp0; ecpp0 lpt

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.

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.

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.

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.

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.

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.

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.

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)

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 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.

Adding Solaris Devices– A more dangerous way of reconfiguring the system on

the fly is to execute the drvconfig, disks, tapes, and dev links commands.

• These four commands cause the sys tem 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.

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.

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.