On 02/24/2012 07:40 AM, Paolo Bonzini wrote:
On 02/24/2012 02:30 PM, Andreas Färber wrote:
SysBus is supposed to go away in Anthony's upcoming 4th QOM series, so
I'd rather not base a new series on that.
Not sure about that. I haven't understood well the scope of the series,
but I think it only converted buses to QOM, it didn't kill them.
Perhaps SysBus was special, in which case it would become automatically
hotpluggable: just create a new QOM object.
The issue with TYPE_DEVICE is that we don't want to leak that into the
user emulators (would break the build), and any infrastructure only
available to qdev should gradually be made accessible to all objects
(Paolo has done some work in that direction wrt properties).
I haven't, but it would be next on the list of things to do.
So the main remaining difference between Object and Device is the
GPIO IRQ support. Anthony wanted to introduce Pin objects to replace
qemu_irq.
Aiming at "replacing" is a bad idea unless you can do it fast and
painlessly. Adding gpio_in and gpio_out property types would be more
useful and would let you expose qemu_irq as QOM.
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.
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.
Regards,
Anthony Liguori
You can then change
the existing qdev.c functions to operate on those new property types.
Paolo
