3. The Plug-and-Play (PnP) Solution

3.1 Introduction to PnP

The term Plug-and-Play (PnP) has various meanings. In the broad sense it is just auto-configuration where one just plugs in a device and it configures itself. In the sense used in this HOWTO, the configuration is only that of configuring PnP bus-resources and letting the device drivers know about it. In a narrower sense it is just setting bus-resources in the hardware devices. For the case of Linux, it is often just a driver giving a command to set the bus-resources in it's device or determining how the BIOS has set them. "PnP" often means just PnP on the ISA bus so the message from isapnp: "No Plug and Play device found" just means that no ISA PnP devices were found. The standard PCI specifications (which are not called "PnP") provide the equivalent of PnP for the PCI bus.

PnP matches up devices with their device drivers and specifies their communication channels. On the ISA bus before Plug-and-Play the bus-resources were formerly set in hardware devices by jumpers. Software drivers were assigned bus-resources by configuration files (or the like) or by probing the for the device at addresses where it's expected to reside. The PCI bus was PnP-like from the beginning but at first it wasn't called PnP (and often still isn't called PnP). While the PCI bus specifications don't use the term PnP it supports in hardware what today is called PnP.

3.2 How It Works (simplified)

Here's an oversimplified view of how PnP should work. The PnP configuration program finds all PnP devices and asks each what bus-resources it needs. Then it checks what bus-resources (IRQs, etc.) it has to give away. Of course, if it has reserved bus-resources used by non-PnP (legacy) devices (if it knows about them) it doesn't give these away. Then it uses some criteria (not specified by PnP specifications) to give out the bus-resources so that there are no conflicts and so that all devices get what they need (if possible). It then tells each physical device what bus-resources are assigned to it and the devices set themselves up to use only the assigned bus-resources. Then the device drivers somehow find out what bus-resources their devices use and are thus able to communicate effectively with the devices they control. In Linux all this is done by the BIOS and/or kernel and/or device drivers in a non-centralized manner.

For example, suppose a card needs one interrupt (IRQ number) and 1 MB of shared memory. The PnP program reads this request from the card. It then assigns the card IRQ5 and 1 MB of memory addresses space, starting at address 0xe9000000. It's not always this simple as the card (or routing table for PCI) may specify that it can only use certain IRQ numbers or that the 1 MB of memory must lie within a certain range of addresses. The details are different for the PCI and ISA buses with more complexity on the ISA bus.

There are some shortcuts that PnP software may use. One is to keep track of how it assigned bus-resources at the last configuration (when the computer was last used) and reuse this. Windows9x (and later) and PnP BIOSs do this but standard Linux doesn't. Windows9x (and later) stores this info in its "Registry" on the hard disk and a PnP BIOS stores it in non-volatile memory in your PC (known as ESCD; see The BIOS's ESCD Database).

While MS Windows (starting with Windows 95) is a PnP OS, Linux was not originally a PnP OS but has been gradually becoming a PnP OS. PnP originally worked in Linux because a PnP BIOS would configure the bus-resources and the device drivers would find out (using programs supplied by the Linux kernel) what the BIOS has done. Today, most drivers can issue commands to do their own configuring and don't need to rely on the BIOS. Unfortunately a driver might take a bus-resource needed by another device). Some device drivers store the last configuration they used and use it the next time the computer is powered on.

If the device hardware remembered their previous configuration, then there wouldn't be any hardware to configure at the next boot-time, but they seem to forget their configuration when the power is turned off. Some devices contain a default configuration (but not necessarily the last one used). Thus a PnP needs to be re-configured each time the PC is powered on. Also, if a new device has been added, then it too needs to be configured. Allocating bus-resources to this new device might involve taking some bus-resources away from an existing device and assigning the existing device alternative bus-resources that it can use instead. At present, Linux can't allocate with this sophistication.

3.3 Starting Up the PC

When the PC is first turned on the BIOS chip runs its program to get the computer started (the first step is to check out the hardware). If the operating system is stored on the hard-drive (as it normally is) then the BIOS must know about the hard-drive. If the hard-drive is PnP then the BIOS may use PnP methods to find it. Also, in order to permit the user to manually configure the BIOS's CMOS and respond to error messages when the computer starts up, a screen (video card) and keyboard are also required. Thus the BIOS must always PnP-configure devices needed to load the operating system from the hard-drive.

Once the BIOS has identified the hard-drive, the video card, and the keyboard it is ready to start booting (loading the operating system into memory from the hard-disk). If you've told the BIOS that you have a PnP operating system (PnP OS), it should start booting the PC as above and let the operating system finish the PnP configuring. Otherwise, a PnP-BIOS will (prior to booting) likely try to do the rest of the PnP configuring of devices (but not informing their drivers).

3.4 Buses

ISA is the old bus of the old IBM PCs while PCI is a newer and faster bus from Intel. The PCI bus was designed for what is today called PnP. It makes it easy (as compared to the ISA bus) to find out how PnP bus-resources have been assigned to hardware devices. To see what has happened use the commands lspci or scanpci (Xwindows) and/or look at /proc/pci or /proc/bus/pci. The boot-up messages on your display are useful (use shift-PageUp to back up thru them). See Boot-time Messages

For the ISA bus there was a real problem with implementing PnP since no one had PnP in mind when the ISA bus was designed and there are almost no I/O addresses available for PnP to use for sending configuration info to physical device. As a result, the way PnP was shoehorned onto the ISA bus is very complicated. Whole books have been written about it. See PnP Book. Among other things, it requires that each PnP device be assigned a temporary "handle" by the PnP program so that one may address it for PnP configuring. Assigning these "handles" is call "isolation". See ISA Isolation for the complex details.

Eventually, the ISA bus should become extinct. When it does, PnP will be easier since it will be easy to find out how the BIOS has configured the hardware. There will still be the need to match up device drivers with devices and also a need to configure devices that are added when the PC is up and running.

3.5 How Linux Does PnP

Linux has had serious problems dealing with PnP and still has a problem but it's not as severe as it once was. Linux still is not really a PnP operating system and seems to mainly rely on and device drivers and the PnP BIOS to configure bus-resources for devices. But the kernel provides help for the drivers in the form of PnP programs they may call on. In many cases, the device driver does all the needed configuring. In other cases the BIOS may configure and then the device driver may find out how the BIOS has configured it. The kernel provides the drivers with some functions (program code) that the drivers may use to find out if their device exists, how it's been configured, and functions to modify the configuration. Kernel 2.2 could do this only for the PCI bus but Kernel 2.4 has this feature for both the ISA and PCI buses (provided that the PNP options have been selected when compiling the kernel). This by no means guarantees that all drivers will fully and correctly use these features.

In addition, the kernel helps avoid resource conflicts by not allowing two devices to use the same bus-resources at the same time. Originally this was only for IRQs, and DMAs but now it's for address resources as well. For PCI, it allocates address resources while booting.

Prior to Kernel 2.4, the standalone program: isapnp was often run to configure and/or get info from PnP devices on the ISA bus. isapnp is still needed for cases where the device driver is not fully PnP for the ISA bus.. There was at least one attempt to make Linux a true PnP operating system. See http://www.astarte.free-online.co.uk. But it never was put into the kernel.

To see what help the kernel may provide to device drivers see the kernel documentation. This documentation (if you have it) is a directory /usr/.../.../Documentation where one of the ... contains the word "kernel". Use the "locate" command to find it. In this documentation directory see pci.txt ("How to Write Linux PCI Drivers") and the file: /usr/include/linux/pci.h. Unless you are a driver guru and know C Programming, these files are written so tersely that they will not actually teach you how to write a driver. But it will give you some idea of what PnP type functions are available for drivers to use. For the ISA bus see isapnp.txt and possibly (for kernel 2.4) /usr/include/linux/isapnp.h.

When the PC starts up you may note from the messages on the screen that some Linux device drivers often find their hardware devices (and the bus-resources the BIOS has assigned them). But there are a number of things that a real PnP operating system could handle better:

• Allocate bus-resources when they are in short supply
• Deal with more than one driver for a physical device
• Find a driver for a detected device (instead of making drivers do the searching)
• Central allocation of bus-resources would ease the job of programmers of device drivers

The "shortage of bus-resources" problem is becoming less of a problem for two reasons: One reason is that the PCI bus is replacing the ISA bus. Under PCI there is no shortage of IRQs since IRQs may be shared (even though sharing is less efficient). Also, PCI doesn't use DMA resources (although it does the equivalent of DMA without needing such resources).

The second reason is that more and more physical devices are using main memory addresses instead of IO address space. On 32-bit PCs there is 4GB of main memory address space and much of this bus-resource is available for device IO (unless you have 4GB of main memory installed). Compare this to the IO address space which is limited to 64KB. So the memory space for device IO is not (yet ?) in short supply.