Plug-and-Play is a way to automatically (low-level) configure cards and other devices you have in your computer and then tell the appropriate device driver what has been done. Plug-and-Play's task is to match up physical devices with the software (device drivers) that operates them and to establish channels of communication between each device and its driver. Put another way, PnP allocates the following "resources" to both drivers and hardware: I/O addresses, IRQ's, DMA channels, memory regions. If you don't understand what these 4 items are read the following subsections. Once these resources have been assigned, the names for devices in the /dev directory are ready to use (provided that the device physically exists on your PC).
Thus PnP configures resources, but it only configures certain resources. Even with PnP fully utilized, much configuring of devices is done by other than PnP. For modem configuration, an "init string" is sent to the modem over the I/0 address "channel". This "init string" has nothing to do with PnP although the "channel" used to send it to the modem was allocated by PnP. Setting the speed (and many other parameters) of a serial port is done by sending messages to the device driver from programs run by the user (often automatically boot-time). This configuration also has nothing to do with PnP. Thus when talking about PnP, "resources" means only a limited subset of resources and "configuring" means only a certain type of configuring.
A computer consists of a CPU/processor to do the computing and memory to store programs and data. In addition, there are a number of devices such as various kinds of disk-drives, a video card, keyboard, network cards, modem cards, sound cards, serial and parallel ports, etc. There is also a power supply to provide electric energy, various buses on a motherboard to connect the devices and the CPU together, and a case to put all this into.
In olden days most all devices had their own plug-in cards (printed circuit boards). Today, in addition to plug-in cards, many "devices" are small chips permanently mounted on a single board called the "motherboard". Cards which plug into the motherboard may contain more than one device. Memory chips are also sometimes considered to be devices but are not plug-and-play in the sense used in this HOWTO.
For the computer system to work right, each device must be under the control of its "device driver" (software which is a part of the operating system and which runs on the CPU). Device drivers are associated with "special files" in the /dev directory although they are not really files. They have names such as hda1 (first partition on hard drive a), ttyS0 (the first serial port), eth1 (the second ethernet card), etc. To make matters more complicated, the particular device driver selected, say for eth1, will depend on the type of ethernet card you have. Thus eth1 can't just be assigned to any ethernet driver but to a certain driver that will work for the type of ethernet card you have installed. To control a device, the CPU (under the control of the device driver) sends commands to and reads info from the various devices. In order to do this each device driver must know the address used for such communication. Knowing such an address is equivalent to setting up a communication channel, even though that "channel" is actually the data bus inside the PC which is shared with almost everything else.
PC's have 3 address spaces: main memory, I/O, and configuration (only on the PCI bus). Only the first two (memory and I/O) are configured by PnP. All of these 3 types of addresses share the same bus inside the PC. (In addition, for the case of the PCI bus, the bus is also used for data). But the voltage on certain dedicated wires tells all devices whether or not an address is in I/O space or in main memory space. Devices are normally located in I/O address space (although in some cases they are also allocated space in main memory). An I/0 address is sometimes just called "I/O", "IO", "i/o" or "io". The term "I/O port" also used. There are two main steps to allocate the I/O addresses, etc.: (just what "etc." includes will be explained shortly)
A third step is to give the device and its driver a name in the /dev directory such as hda, ttyS0, or eth1. The two step process above is something like the problem of finding someone's house number on a street. You must know the house number and and someone must install a number on the front of the house so that it may be found. In computers, the device driver must know the address and the device hardware must install the same address in one of its registers. Both of these must be done, but some people make the mistake of doing only one of these and then wonder why the computer can't find the device. Now to explain (in the next 3 sections) what the "etc." above includes: IRQ's, DMA Channels, and Memory Regions. All of these (including I/O addresses) are called "resources".
After reading this you may read Interrupts --Details for some more details. The following is intentionally oversimplified: Besides the address, there is also an interrupt number to deal with (such as IRQ5). It's called an IRQ (Interrupt ReQuest) number. We already mentioned above that the device driver must know the address of a card in order to be able to communicate with it. But what about communication in the opposite direction? Suppose the the device needs to tell its device driver something immediately? Thus the device needs to know the address (or the like) of it's device driver so that it can call it for help. For example, the device may have just received a lot of bytes destined for main memory and the device needs to call its driver to fetch these bytes at once and transfer them from the device's nearly full buffer into main memory.
The device calls for such help by putting a voltage on an interrupt wire (part of the bus). There are the equivalent of 16 wires and each wire leads (indirectly) to a certain device driver. Each wire has a unique IRQ (Interrupt ReQuest) number. The device must put its interrupt on the correct wire and the device driver must listen for the interrupt on the correct wire. Which wire it's put on is determined by the IRQ number stored in the device. This same IRQ number must be known to the device driver so that the device driver knows which IRQ line to listen to.
DMA stands for "Direct Memory Access". This is where a device is allowed to take over the main computer bus from the CPU and transfer bytes directly to main memory. Normally the CPU would make such a transfer in a two step process: 1. reading from the I/O memory space of the device, putting these bytes into the CPU itself 2. writing these byte from the CPU to main memory. With DMA it's usually a one step process of sending the bytes directly from the device to memory. The device must have such capabilities built into its hardware and thus not all devices can do DMA. While DMA is going on the CPU can't do much since the main bus is being used by The DMA transfer.
When a device wants to do DMA it issues a DMA-request using dedicated DMA request wires much like an interrupt request. DMA actually could have been handled by using interrupts but this would introduce some delays so it's faster to do it by having a special type of interrupt known as a DMA-request. Like interrupts, DMA-request are numbered so as to identify which device is making the request. This number is called a DMA-channel. Since DMA transfers all use the main bus (and only one can run at a time) they all actually use the same channel but the "DMA channel" number serves to identify who is using the "channel". Hardware registers exist on the motherboard which store the current status of each "channel". Thus in order to issue a DMA-request, the device must know its DMA-channel number which must be stored in a register on the physical device.
Some devices are assigned address space in main memory as well as in I/O address space. When you plug in such a card, you are in effect also plugging in a memory module (for main memory, not just I/O memory). This memory is shared between the device and the CPU (running the device driver). This memory can serve as a means of direct data "transfer" between the device and main memory. It's not really a transfer since the device puts data into its own memory which also happens to be main memory. Both the card and the device driver need to know where it is.
Thus device drivers must be "attached" in some way to the hardware they control. This is done by supplying "resources" (I/O, Memory, IRQ's, DMA's) to both the physical device and the device driver software. For example, in the case of a serial port there are only 2 (out of 4 possible) resources: an IRQ and an I/O address. Both of these values must be supplied to the device driver and the physical device. The driver (and its device) is then given a name (such as ttyS1). The address and IRQ number is stored by the physical device in a register on the card (or in a chip on the motherboard).
The architecture of the PC provides only a limited number of IRQ's, DMA channels, I/O address, etc. If there were only several devices and they all had standardized resource (such as unique I/O addresses and IRQ numbers) there would be no problem of attaching device drivers to devices. Each device would have a fixed resources which would not conflict with any other device on your computer. No two devices would have the same I/O address, IRQ, etc. Each driver would be programmed with the I/O address, IRQ, etc. hard-coded into the program. Life would be simple.
But it's not. Not only are there so many different devices today that conflicts are likely, but but one sometimes needs to have more than one of the same type of device. For example one may want to have a few different disk-drives, a few serial ports, etc. For these reasons devices need to have some flexibility so that they can be set to whatever address, IRQ, etc. is needed to avoid conflicts. But some IRQ's and addresses are pretty standard such as the ones for the clock and keyboard. These don't need such flexibility.
Besides the problem of conflicting allocation of resources, there is a problem of making a mistake in telling the device driver what the resources are. For example, suppose that you enter IRQ 4 in a configuration file when the device is actually set at IRQ 5. This is another type of resource allocation error.
The allocation of resources, if done correctly, also establishes channels of communication between physical hardware and their device drivers. For example, if a certain I/O address range (resource) is allocated to both a device driver and a piece of hardware, then this has established a one-way communication channel between them. The driver may send commands and info to the device. It's actually a little more than one-way since the driver may get information from the device by reading it's registers. But the device can't initiate any communication this way. Allocating an IRQ makes it a two-way communication channel where both the driver and the device can initiate communication.