kenh@cmf.nrl.navy.mil said:
> In my reading of the PCI 2.1 spec, the BIOS is only required to do
> this for devices that the hardware needs to boot.

That's an issue I haven't found clear words in the standards
for. PCI2.1 does indeed say that the initialization is needed
for boot devices, but it doesn't state that it is not needed
for the rest. Older documents require initialization for
all -- there is eg a "PCI system design guide" rev 1.0
from the PCI SIG which says: "Another task of the POST code
is to map all I/O devices into appropriate locations in the
address spaces, providing enough initialization so that device
drivers can use them." (pg. 7-4)
And, in some course material of a "Critical PCI Design Workshop"
held by high-rated PCI gurus (Hosler/Rasmussen/Solari) in October 
a "typical" POST flow contains "Search for and Configure devices".
(transparency nr. 83, in case it helps someone:-)
This all looks like the original spririt and letter of the
standard is weakened silently, and there are business issues
which prevents this from being said clearly.

It's obvious that the BIOS/POST idea doesn't hold when it
comes to hot-plug PCI. All the plug-and-play BIOS stuff
related to live reconfiguration is - frankly - rubbish if one
is serious about 32-bit processors and -OSs, so after all the OS
has really to care.
This is not necessarily a reason to shrink BIOS support for
OSs which don't do this (like NetBSD, but many others too),
and which therefore can't support hot-plug, but obviously W9X
compliance is what counts.

So as long as there is a BIOS item "no PnP OS" (what a misnomer
indeed) things are OK, but it's questionable how long one
can rely on this.
One day, we'll have to do complete ressource management.

> This brings up the next question - exactly what _is_ the right magic?
> We should be talking to the PCI BIOS, right?  How come we aren't?

The PCI BIOS alone doesn't help much, it's for configuration space
access and so. And even this brings only one additional level of
uncertainity which can be avoided because the hardware interface is
well-defined. (There are some chipsets known for violating the spec,
but I guess there are much more buggy BIOSes around.) There is a
"Plug and Play BIOS Specification" rev. 1.0a from 1994 which gives access
to configuration data and hot-plug events, but a good deal of this (the
ESCD stuff) seems depreciated in the meantime. Besides this, there
is no 32-bit protected mode interface.

The whole BIOS stuff is a nightmare do deal with, so I'd say
we should do the hardware recognition as good as possible, and
extend the ressource accounting to account for unrecognized
devices as well (and for unused spaces of recognized devices).
Perhaps the ressource maps can use BIOS provided information
initially, but it should be possible to rely only on "trusted"
code at runtime.

best regards
Matthias