On Sun, Jun 10, 2012 at 01:18:15PM +0200, Jan Kiszka wrote: > >>>>>> @@ -318,6 +322,9 @@ PCIBus *pci_register_bus(DeviceState *parent, > >>>>>> const char *name, > >>>>>> MemoryRegion *address_space_io, > >>>>>> uint8_t devfn_min, int nirq); > >>>>>> PCIINTxRoute pci_device_route_intx_to_irq(PCIDevice *dev, int pin); > >>>>>> +void pci_bus_fire_intx_routing_notifier(PCIBus *bus); > >>>>> > >>>>> Well true it fires the notifier but what it does conceptually > >>>>> is update intx routing. > >>>> > >>>> Nope, it informs about updates _after_ they happened. > >>> > >>> Don't we need to update the cached pin if this happens? > >>> If yes I would this a better API would both update the cache > >>> and then trigger a notifier. > >>> And the notifier can then be cache change notifier, > >>> and the "fire" function would instead be "update_cache". > >> > >> See above, the cached part of the route is static anyway. What changes > >> is the host bridge configuration. > > > > You are saying it is only the intx to irq routing that > > can change? > > So maybe "pci_bus_update_intx_to_irq_routing"? > > Again, this function does not _update_ anything. It informs about a > host-bridge-specific update, i.e. something that happened outside the > generic code beforehand.
Yes it does what it says but it's an ugly interface all the same. What does a host device emulation care about notifiers? It's an implementation detail. The *real* reason is that someone caches intx to irq routing and you need to update that cache. So just say so. -- MST