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

[Anthony Liguori]

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