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, …).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
![Chapter Goals ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)