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 ioctls as standard, and specific
variants of UNIX define several other “proprietary” ioctls.
• 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 out-put 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.
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.
37. 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
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 sysctla 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 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.
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
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.
