On the Internet, address information was initially stored in a single HOSTS.TXT database, too. This file was maintained at the Network Information Center (NIC), and had to be downloaded and installed by all participating sites. When the network grew, several problems with this scheme arose. Besides the administrative overhead involved in installing HOSTS.TXT regularly, the load on the servers that distributed it became too high. Even more severe, all names had to be registered with the NIC, which made sure that no name was issued twice.
This is why a new name resolution scheme was adopted in 1994: the Domain Name System. DNS was designed by Paul Mockapetris and addresses both problems simultaneously. We discuss the Domain Name System in detail in Chapter 6.
Chapter 3. Configuring the Networking Hardware
We've been talking quite a bit about network interfaces and general TCP/IP issues, but we haven't really covered what happens when the "networking code" in the kernel accesses a piece of hardware. In order to describe this accurately, we have to talk a little about the concept of interfaces and drivers.
First, of course, there's the hardware itself, for example an Ethernet, FDDI or Token Ring card: this is a slice of Epoxy cluttered with lots of tiny chips with strange numbers on them, sitting in a slot of your PC. This is what we generally call a physical device.
For you to use a network card, special functions have to be present in your Linux kernel that understand the particular way this device is accessed. The software that implements these functions is called a device driver. Linux has device drivers for many different types of network interface cards: ISA, PCI, MCA, EISA, Parallel port, PCMCIA, and more recently, USB.
But what do we mean when we say a driver "handles" a device? Let's consider an Ethernet card. The driver has to be able to communicate with the peripheral's on-card logic somehow: it has to send commands and data to the card, while the card should deliver any data received to the driver.
In IBM-style personal computers, this communication takes place through a cluster of I/O addresses that are mapped to registers on the card and/or through shared or direct memory transfers. All commands and data the kernel sends to the card have to go to these addresses. I/O and memory addresses are generally described by providing the starting or base address. Typical base addresses for ISA bus Ethernet cards are 0x280 or 0x300. PCI bus network cards generally have their I/O address automatically assigned.
Usually you don't have to worry about any hardware issues such as the base address because the kernel makes an attempt at boot time to detect a card's location. This is called auto probing, which means that the kernel reads several memory or I/O locations and compares the data it reads there with what it would expect to see if a certain network card were installed at that location. However, there may be network cards it cannot detect automatically; this is sometimes the case with cheap network cards that are not-quite clones of standard cards from other manufacturers. Also, the kernel will normally attempt to detect only one network device when booting. If you're using more than one card, you have to tell the kernel about the other cards explicitly.
Another parameter that you might have to tell the kernel about is the interrupt request line. Hardware components usually interrupt the kernel when they need to be taken care of - for example, when data has arrived or a special condition occurs. In an ISA bus PC, interrupts may occur on one of 15 interrupt channels numbered 0, 1, and 3 through 15. The interrupt number assigned to a hardware component is called its interrupt request number (IRQ).[17]
As described in Chapter 2, Issues of TCP/IP Networking, the kernel accesses a piece of network hardware through a software construct called an interface. Interfaces offer an abstract set of functions that are the same across all types of hardware, such as sending or receiving a datagram.
Interfaces are identified by means of names. In many other Unix-like operating systems, the network interface is implemented as a special device file in the /dev/ directory. If you type the ls -las /dev/ command, you will see what these device files look like. In the file permissions (second) column you will see that device files begin with a letter rather than the hyphen seen for normal files. This character indicates the device type. The most common device types are b, which indicates the device is a block device and handles whole blocks of data with each read and write, and c, which indicates the device is a character device and handles data one character at a time. Where you would normally see the file length in the ls output, you instead see two numbers, called the major and minor device numbers. These numbers indicate the actual device with which the device file is associated.
Each device driver registers a unique major number with the kernel. Each instance of that device registers a unique minor number for that major device. The tty interfaces,/dev/tty*, are a character mode device indicated by the " c ", and each have a major number of 4, but /dev/tty1 has a minor number of 1, and /dev/tty2 has a minor number of 2. Device files are very useful for many types of devices, but can be clumsy to use when trying to find an unused device to open.
Linux interface names are defined internally in the kernel and are not device files in the /dev directory. Some typical device names are listed later in "A Tour of Linux Network Devices"." The assignment of interfaces to devices usually depends on the order in which devices are configured. For instance, the first Ethernet card installed will become eth0, and the next will be eth1. SLIP interfaces are handled differently from others because they are assigned dynamically. Whenever a SLIP connection is established, an interface is assigned to the serial port.
Figure 3.1 illustrates the relationship between the hardware, device drivers, and interfaces.
Figure 3.1: The relationship between drivers, interfaces, and hardware
When booting, the kernel displays the devices it detects and the interfaces it installs. The following is an excerpt from typical boot messages:
.
. This processor honors the WP bit even when in supervisor mode./
Good.
Swansea University Computer Society NET3.035 for Linux 2.0
NET3: Unix domain sockets 0.13 for Linux NET3.035.
Swansea University Computer Society TCP/IP for NET3.034
IP Protocols: IGMP,ICMP, UDP, TCP
Swansea University Computer Society IPX 0.34 for NET3.035
IPX Portions Copyright (c) 1995 Caldera, Inc.
Serial driver version 4.13 with no serial options enabled
tty00 at 0x03f8 (irq = 4) is a 16550A
tty01 at 0x02f8 (irq = 3) is a 16550A
CSLIP: code copyright 1989 Regents of the University of California
PPP: Version 2.2.0 (dynamic channel allocation)
PPP Dynamic channel allocation code copyright 1995 Caldera, Inc.
PPP line discipline registered.
eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 a0 24 0e e4 e0,/
IRQ 10.
3c509.c:1.12 6/4/97 becker@cesdis.gsfc.nasa.gov
17
IRQs 2 and 9 are the same because the IBM PC design has two cascaded interrupt processors with eight IRQs each; the secondary processor is connected to IRQ 2 of the primary one.