Saab Dastard:
I do remember it being referred to as Plug and Pray.
But since then, I have not, to my knowledge, had a P&P related issue.
Are you referring to the BIOS level or the OS level - or both?
The plug and pray was the issue in the early days as when P&P was first introduced there were alot of cards that were not P&P and as you rightly say the jumpers had to be set to avoid conflicts.
If we look to what actually happens in a simplistic manner (You may know this but will provide a full explanation for those that dont) it will be alot clearer.
An IO card will function whilst the CPU is busy doing something else for example a network card will montior network traffic and receive until its buffer is full. When the card has something to provide to the CPU it will raise the interrupt line to the CPU alerting that it is ready. The CPU will then tell the card to put its information in an area of memory and will notify the MMU (Memory Management Unit) to move this data when it arrives to a specific location where the driver can access it.
The point of P&P and jumpers is to identify where in memory to place this temporary information for the MMU to access. Each card will require a different memory location so that it does not overwrite any information from other cards.
With P&P each card on start up will interrogate the P&P controller to see where it would like the information to be placed - so with each power on of the system if the configuration has changed the controller may provide a different address for the card to use.
When not using P&P when the system is first powered on a P&P card will default to a location and look to see if it is being used. If it is not it will use the location, if it detects a conflict it will move. Thus each time you add a card to a system it will go through the conflict resolution process. But in this instance if you remove a card it will not change the address on any existing cards remaining.
Plug and Pray was the name given because the older jumpered cards were not aware of the P&P controllers actions that could result in conflict and the P&P controller expects no conflict resolution for non P&P cards as it was assuming it had full rights over the whole address space. The answer was to switch P&P off so that each P&P card would manage conflict resolution with the jumpered cards and move elsewhere.
Legacy P&P on an OS Level is purely setting the bios of a card to a known address that is free by means of the OS detecting what is already installed - however the downfall of this legacy method was that if OS did not have the driver loaded it was not aware that a card may already be installed and could generate conflict.
Modern P&P in operating systems interrogates the P&P controller on boot to see what devices it is serving and where they are, it matches this to its current known list to see if anything has changed and whether a driver needs loading.
A well behaved driver should not care where a card places its transient information in memory however some drivers rather than let the MMU manage the memory try to manage it themselves. Thus when the P&P controller moves adresses of devices all can get a bit screwey and drivers have to be unloaded and reloaded. This issue exists as on a processor level the drivers run at the same protection level as the operating system and therefore have full remit over the physical memory of the whole machine. If anyone needs me to explain protection levels let me know - I think I have put most to sleep by now already lol.
Cheers
Jof