> Imagine that one application has  five devices on PCI0.  One day, it requires to
> hot adding   two more  PCI devices while the system has
> been serving  for three months.  However, the application can not
> disturb any other devices on PCI1 - at least for the prebuilt 1GHZ
> network.  What is the new bus number for the two added devices
> based on the original proposal  ?

Maybe I don't understand exactly what you are asking, but it is as simple as seems, then the two added devices have the same bus number as the other five devices on the PCI0 bridge.  All devices on a single bus segment have the same bus number.
If one of the cards installed has a bridge, then the secondary devices on that card have a higher bus number.  If there are no other busses in the system, all devices on PCI0 would probably have bus number 0, all devices on PCI1 would have bus number 1, and if you added a device that contained a bridge onto the bus segment from PCI0, it would be assigned bus number 2.

> I  truly doubt one can predict how hardware vendor would design the bus architecture.

Which is why a PCI API should not make any assumptions about the bus architecture beyond what is explicit in the bus specification.
PCI devices are identified by bus segment number, device number, and function number.  Anything beyond that is implementation specific, and so should not properly be part of a PCI API.

The PCI specification and the PCI BIOS specification are a good place to start.  The PCI BIOS specification was intended to be exactly what we are discussing, a standardized way that bootloader software can access PCI devices to discover the bus topology without having to know specifics of the hardware implementation.  
That spec is heavily IA32-centric, but Intel has driven the PCI specs to a large degree, so not completely unexpected.  What is described in the PCI BIOS specification would have to be implemented in BSP specific code for RTEMS.  Some piece of code has to know how to cause the particular hardware to initiate a configuration cycle, has to know the register layout, etc., but the PCI API should abstract all that information so that application code only knows about PCI information, and any translation between PCI information and hardware specific information should be handled by BSP specific code.

-- Chris Caudle


