Date post: | 24-May-2015 |
Category: |
Technology |
Upload: | raja-waseem-akhtar |
View: | 355 times |
Download: | 0 times |
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.