[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 05/15] qdev: allow multiple qdev_init_gpio_in
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH v5 05/15] qdev: allow multiple qdev_init_gpio_in() calls |
Date: |
Tue, 7 Aug 2012 09:03:16 +0100 |
On 7 August 2012 01:12, Peter Crosthwaite
<address@hidden> wrote:
> On Mon, Aug 6, 2012 at 7:38 PM, Peter Maydell <address@hidden> wrote:
>> On 6 August 2012 03:16, Peter A. G. Crosthwaite
>> <address@hidden> 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
[Qemu-devel] [PATCH v5 09/15] hw: Added generic FIFO API., Peter A. G. Crosthwaite, 2012/08/05