On Tue, Jun 16, 2026 at 05:22:05PM +0100, Peter Maydell wrote:
> On Tue, 16 Jun 2026 at 16:57, Daniel P. Berrangé <[email protected]> wrote:
> >
> > Prepare for the move to dynamically allocated IRQ objects by
> > introducing qemu_irq_new / qemu_irq_new_child / qemu_irq_new_array
> > functions which call through to object_new instead of object_initialize.
> >
> > Signed-off-by: Daniel P. Berrangé <[email protected]>
> > ---
> >  hw/core/irq.c         | 35 ++++++++++++++++++++
> >  include/hw/core/irq.h | 75 ++++++++++++++++++++++++++++++++++++++++---
> >  2 files changed, 106 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/core/irq.c b/hw/core/irq.c
> > index 106805e241..e943c87b81 100644
> > --- a/hw/core/irq.c
> > +++ b/hw/core/irq.c
> > @@ -49,6 +49,13 @@ void qemu_init_irq(IRQState *irq, qemu_irq_handler 
> > handler, void *opaque,
> >      init_irq_fields(irq, handler, opaque, n);
> >  }
> >
> > +IRQState *qemu_irq_new(qemu_irq_handler handler, void *opaque, int n)
> > +{
> > +    IRQState *irq = IRQ(object_new(TYPE_IRQ));
> > +    init_irq_fields(irq, handler, opaque, n);
> > +    return irq;
> > +}
> 
> Isn't this the same as the existing qemu_allocate_irq() ?

Doh, I missed the very surprising naming pattern where "qemu_irq" is a
typedef of 'struct IRQState *'.

> (I have over the past few years occasionally been trying to get rid
> of existing uses of qemu_allocate_irq() and its cousin
> qemu_allocate_irqs(), because they are persistent sources of memory
> leaks. The function returns a pointer that the caller has to deal
> with and remember to free, whereas using e.g. qdev_init_gpio_*()
> makes the new irq objects children of the device they belong to,
> so they're automatically freed when the device is destroyed.
> qemu_init_irq_child() similarly.)

If we think it is best practice to mandate passing in a parent
object so that every IRQ  is gauranteed to be owned by the QOM
tree, that's fine with me.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|


Reply via email to