On 7 August 2012 01:12, Peter Crosthwaite <peter.crosthwa...@petalogix.com> wrote: > On Mon, Aug 6, 2012 at 7:38 PM, Peter Maydell <peter.mayd...@linaro.org> > wrote: >> On 6 August 2012 03:16, Peter A. G. Crosthwaite >> <peter.crosthwa...@petalogix.com> wrote: >>> + qemu_irq *all_irqs = g_new(qemu_irq, n + dev->num_gpio_in); >>> + memcpy(all_irqs, dev->gpio_in, sizeof(*all_irqs) * >>> dev->num_gpio_in); >>> + g_free(dev->gpio_in); >>> + memcpy(&all_irqs[dev->num_gpio_in], new_irqs, sizeof(*all_irqs) * >>> n), >>> + g_free(new_irqs); >> >> I think this is rather looking into private details of what >> qemu_allocate_irqs >> does, and it would be better to define a new qemu_reallocate_irqs() in irq.c >> so we can use it here. (when doing so, consider whether g_renew() might help >> in producing nice looking code) > > My understanding is Anthony is doing major refactoring in the GPIO > area anyways. Long term, will this code in qdev.c/irq.c even going to > exist? In this patch, I took something of a path of least resistance > to just make this series work, as I suspect this patch in its current > form will be short lived due to continued QOM development.
Yes, long term this will all disappear, but I wouldn't hold your breath (and indeed it's because I don't think the Pin reworking will hit before next release that I think this patch makes sense at all). But it will be around for a fair while, which is why the code should be in the right place. It's only adding a five or ten line function to irq.c. -- PMM
