On 01/26/2012 09:36 PM, Anthony Liguori wrote: > On 01/26/2012 01:12 PM, Peter Maydell wrote: >> On 26 January 2012 19:00, Anthony Liguori<aligu...@us.ibm.com> wrote: >>> We need to modeled MemoryRegions and qemu_irq in QOM too. >> >> +1 : this ought to let us get rid of SysBus... >> >>> MemoryRegions >>> shouldn't be that difficult. Our habit of passing qemu_irq's as >>> arrays without >>> an explicit size will probably require some refactoring but in >>> principle, >>> supporting irqs should be easy too. >> >> I think that there are probably a lot of cases where we're using an >> array >> of qemu_irqs now but should be using separately named signals of some >> sort >> instead (particularly where we're using them for things which aren't >> actually >> IRQs...) > > I started hacking up a Pin object that used a Notifier. It's pretty > easy to plumb that to an existing qemu_irq so I think that's the way > to go. > > That way we could incrementally remove qemu_irq usage. > > I started with this path but the pc initialization was so fubar that I > ran into too many problems. Now I think I can go back and do it again > and it will be more reasonable given this refactoring. > > At a high level, a Pin object looks and feels like a qemu_irq. > There's a pin_raise, pin_set_level, etc. But there is also a > pin_get_level() (it's stateful) and there's a > pin_add_level_change_notifier() which allows you to register. > > Pins are objects so they can be added to the composition tree which > means they can be addressed. If you have a truly unidirectional path, > then you can just use a child and link and connect them that way. >
Like. But note: like a MemoryRegion, a Pin reflects state held elsewhere, so it should not be saved/restored. -- error compiling committee.c: too many arguments to function
