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 more narrow sense it just setting bus-resources in the hardware devices. It may also mean the PnP specifications which (among other things) specify how PnP resource data is to be read and written to devices (often cards) on the ISA bus. The standard PCI (and not PnP) specifications do the same 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 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 so it was trivial to implement PnP for this bus. Since the PCI bus specifications don't use the term PnP it's not clear whether or not the PCI bus should be called PnP (but it supports in hardware what today is called PnP).
Here's an oversimplified view of how PnP works. The PnP configuration program (perhaps a program in the BIOS) 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's not always this simple as the card may specify that it can only use certain IRQ numbers (ISA only) 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 PnP BIOSs do this but standard Linux doesn't. Windows9x 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).
Under Linux it's each device for itself and there is no centralized non-volatile registry of resource assignments. Some device drivers store the last configuration they used and use it next time the computer is powered on. They implicitly assume that the rest of the hardware will not need to use it's bus-resources.
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 configuration program needs to be run 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.
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 PnP-configure these devices on its own.
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 a 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 their drivers).
ISA is the old bus of the old IBM PC's 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 look at the /proc/pci "file" (/proc/bus/pnp/devices for kernel 2.2+), the boot-up messages on your display (use shift-PageUp to back up), or use PCI Utilities (for kernel 2.2+).
For the ISA bus there is 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. A whole book has 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 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. These needs would be satisfied if Linux was a PnP operating system.
PnP (for the ISA bus) was invented by Compaq, Intel, and Phoenix. Microsoft has been a leading promoter of it. Linux would have been better off if PnP had never been "invented". Eventually the ISA bus will have become extinct and the PnP-like PCI bus will prevail so that we will have in effect gotten an easy-to-implement PnP. But like it or not, most all new ISA hardware today is PnP and Linux has no choice but to deal effectively with PnP. But standard Linux (as of early 1999) makes dealing with PnP complicated (especially on the ISA bus) while the purpose of PnP was to make it simple.
In a sense, Linux is already somewhat PnP for the PCI bus. 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 situations that a PnP operating system could handle better: 1. A shortage of bus-resources 2. More than one driver for a physical device 3. An activated driver which can't find it's physical device 4. Hot installation of a device (docking, etc.)
Linux users should not need to delve into the details of PnP to configure ISA PnP devices as they now need to. One solution would be a standardized version of the Linux kernel that supports Plug-and-Play on the ISA, PCI, and other buses. A patch to the kernel has been written although most drivers don't support it. It's not part of standard Linux. See Patch Kernel.