On Tue, Aug 12, 2014 at 7:16 PM, Alexander Graf <ag...@suse.de> wrote:
>
> On 04.08.14 03:55, Peter Crosthwaite wrote:
>>
>> To replace the old qemu_irq intercept API (which had users reaching
>> into qdev private state for IRQs).
>>
>> Signed-off-by: Peter Crosthwaite <peter.crosthwa...@xilinx.com>
>> ---
>>
>> hw/core/qdev.c | 25 +++++++++++++++++++++++++
>> include/hw/qdev-core.h | 2 ++
>> 2 files changed, 27 insertions(+)
>>
>> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
>> index e6b2231..4cbf773 100644
>> --- a/hw/core/qdev.c
>> +++ b/hw/core/qdev.c
>> @@ -412,6 +412,31 @@ void qdev_connect_gpio_out_named(DeviceState *dev,
>> const char *name, int n,
>> g_free(propname);
>> }
>> +/* disconnect a GPIO ouput, returning the disconnected input (if any)
>> */
>> +
>> +static qemu_irq qdev_disconnect_gpio_out_named(DeviceState *dev,
>> + const char *name, int n)
>> +{
>> + char *propname = g_strdup_printf("%s[%d]",
>> + name ? name : "unnamed-gpio-out",
>> n);
>> +
>> + qemu_irq ret = (qemu_irq)object_property_get_link(OBJECT(dev),
>> propname,
>> + NULL);
>> + if (ret) {
>> + object_property_set_link(OBJECT(dev), NULL, propname, NULL);
>> + }
>> + g_free(propname);
>> + return ret;
>> +}
>> +
>> +void qdev_intercept_gpio_out(DeviceState *dev, qemu_irq_handler handler,
>> + const char *name, int n)
>> +{
>> + qemu_irq disconnected = qdev_disconnect_gpio_out_named(dev, name, n);
>> + qemu_irq icpt = qemu_allocate_irq(handler, disconnected, n);
>
>
> This means that we can't pass in any other opaque to the intercepting
> handler which sounds suboptimal to me. Can't we pass in a qemu_irq as
> parameter and a pointer to a field where we can store the disconnected
> qemu_irq?
>
> Then the caller can allocate its own qemu_irq with all the opaque data it
> wants and just have the intercept function overwrite a single field in the
> passed down opaque.
>
> Or you just return the disconnected qemu_irq. Then the caller can do
> whatever it likes with it, such as set icpt->opaque to it.
>
Good idea. Ill play with these options and see what works best.
Regards,
Peter
>
> Alex
>
>
