Re: [Qemu-devel] [RFC 00/15] Refactor PC machine to take advantage of QOM

[Avi Kivity <avi@redhat.com>]

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<aliguori@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