Re: [Qemu-devel] [RFC 00/15] Refactor PC machine to take advantage of QOM

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/26/2012 01:12 PM, Peter Maydell wrote:
> On 26 January 2012 19:00, Anthony Liguori<aliguori@us.ibm.com>  wrote:
>> We need to modeled MemoryRegions and qemu_irq in QOM too.
>
> +1 : this ought to let us get rid of SysBus...
>
>>   MemoryRegions
>> shouldn't be that difficult.  Our habit of passing qemu_irq's as arrays without
>> an explicit size will probably require some refactoring but in principle,
>> supporting irqs should be easy too.
>
> I think that there are probably a lot of cases where we're using an array
> of qemu_irqs now but should be using separately named signals of some sort
> instead (particularly where we're using them for things which aren't actually
> IRQs...)

I started hacking up a Pin object that used a Notifier.  It's pretty easy to 
plumb that to an existing qemu_irq so I think that's the way to go.

That way we could incrementally remove qemu_irq usage.

I started with this path but the pc initialization was so fubar that I ran into 
too many problems.  Now I think I can go back and do it again and it will be 
more reasonable given this refactoring.

At a high level, a Pin object looks and feels like a qemu_irq.  There's a 
pin_raise, pin_set_level, etc.  But there is also a pin_get_level() (it's 
stateful) and there's a pin_add_level_change_notifier() which allows you to 
register.

Pins are objects so they can be added to the composition tree which means they 
can be addressed.  If you have a truly unidirectional path, then you can just 
use a child and link and connect them that way.

For a bidirectional path (where software controls the direction at run time), 
you can have an intermediate Wire object which consists of two Pin links.

Regards,

Anthony Liguori

>
> -- PMM
>