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

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/26/2012 01:57 PM, Markus Armbruster wrote:
> Peter Maydell<peter.maydell@linaro.org>  writes:
>
>> 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...)
>
> Apropos array of qemu_irq: we're leaking them in several places.
> qemu_allocate_irqs() returns a pointer to an array of qemu_irq whose
> elements to point into an array of *qemu_irq.  Both arrays are malloced.
>
> Many callers ask for just one IRQ like this:
>
>      *qemu_allocate_irqs(..., 1)
>
> This leaks the array of qemu_irq.
>
> There are other, less obvious leaks of the returned array.

We leak lots of stuff...

One nice thing in QOM is that we can create child devices that use the parent 
device's resources and tie the life cycles together.

So whereas we were leaking all sorts of MemoryRegions and qdev devices before, 
with this series, we do it a whole lot less.

Same principle will apply to IRQs.

Regards,

Anthony Liguori

>