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
