Re: [Qemu-devel] [PATCH 1/7] Introduce a new bus "ICC" to connect APIC

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/24/2012 07:50 AM, Paolo Bonzini wrote:
> On 02/24/2012 02:47 PM, Anthony Liguori wrote:
>>>
>>
>> I agree with you in principle, but in practice, there is not obvious way
>> to serialize gpio_in/gpio_out via Visitors.  Finding some way to do it
>> as an integer is clearly wrong IMHO.
>
> "%s/gpio_in[%d]" % (object_get_canonical_path(...), opaque->n) is what I
> was thinking about.

This creates another namespace that's independent of the QOM graph.  This is 
something we should try to avoid.

>> I think a simple Pin object with the following interfaces:
>>
>> /**
>>   * Connect a pin to a qemu_irq such that whenever the pin is
>>   * raised, qemu_irq_raise() is called too on irq.
>>   */
>> void pin_connect_qemu_irq(Pin *obj, qemu_irq irq);
>>
>> /**
>>   * Returns a qemu_irq such that whenever qemu_irq_raise() is
>>   * called, pin_set_level(obj, true) is called.
>>   */
>> qemu_irq pin_get_qemu_irq(Pin *obj);
>>
>> Let's you incrementally refactor objects to use Pins while maintaining the existing qemu_irq infrastructure.
>
> Sure, a simple bridge is a fine alternative.  What I'm not sure about is
> making Pins stateful, because that means you have to serialize them.

Being stateful is a feature but the concept would work just as well if you 
didn't store the pin state.  Then it just looks like:

struct Pin
{
    Object parent;

    /*< private >*/
    NotifierLister level_change_notifiers;
};

The reason to introduce another type (instead of attempting to convert qemu_irq) 
is that the life cycle of qemu_irq is very un-QOM.  I don't think we can do it 
without incrementally refactoring the users of qemu_irq and a new type makes it 
easier to do that incrementally.

Regards,

Anthony Liguori

> Paolo