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 or switches. 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.
Here's how PnP should work in theory. 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.
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 then informs the device driver of what it's done (except the BIOS can't do this). 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.
One way commonly used to allocate resources is to start with one device and allocate it bus-resources. Then do the same for the next device, etc. Then if finally all devices get allocated resources without conflicts, then all is OK. But if allocating a needed resource would create a conflict, then it's necessary to go back and try to make some changes in previous allocations so as to obtain the needed bus-resource. This is called rebalancing. Linux doesn't do rebalancing but MS Windows does in some cases. For Linux, all this is done by the BIOS and/or kernel and/or device drivers. In Linux the device driver doesn't allocate any resources until the driver starts up, so one way to avoid conflicts is just not to start any device that might cause a conflict.
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 bus-resource configuring and don't need to rely on the BIOS. Unfortunately a driver might take a bus-resource which another device will need later on. Some device drivers may store the last configuration they used in a configuration file 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 device 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 (and MS Windows XP may not be able to do it either).
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 inform their drivers of what it did).
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. This 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's on the PCI bus type lspci. Or type scanpci but it's
not as easy to read. The -v option will show more detail. And/or
look at the "file" /proc/pci. The boot-up messages on your
display show devices which have been found on various buses (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 a 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 this happens, PnP will be a little easier since it will be easier 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.
Linux has had serious problems dealing with PnP and still has a problem but it's not as severe as it once was. It's debatable whether or not Linux is really a PnP operating system. It 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 programs they may call on that do PnP. In many cases, the device driver, with the help of such programs, does all the needed configuring. In some 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 directory /usr/.../.../Documentation where one of the ... contains the word "kernel-doc" or the like. 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:
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.