On 05/01/2012 08:01 AM, Avi Kivity wrote:
On 05/01/2012 03:49 PM, Peter Maydell wrote:
On 1 May 2012 13:48, Avi Kivity<a...@redhat.com>  wrote:
On 05/01/2012 03:43 PM, Peter Maydell wrote:
On 1 May 2012 13:42, Avi Kivity<a...@redhat.com>  wrote:
sysbus should just die.


Totally agreed. It's not going to go quietly though...

Not if you keep suggesting workarounds when I tell unsuspecting
developers to qomify their devices.

When QOM supports (1) exporting gpio signals and

This is trivial. It'll come in as soon as 1.2 opens up. If folks want to start working on a branch with it:

https://github.com/aliguori/qemu/tree/qom-pin.4

(2) exporting memory regions, then it will be providing the
main things that sysbus provides.

This is a little tricky.  Here's the problems I've encountered so far:

a) A lot of devices need the equivalent of it_shift. it_shift affects how addresses are decoded and the size of the memory region. it_shift usually needs to be a device property.

Since we need to know the size of the memory region to initialize it, we need to know the value of it_shift before we can initialize it which means we have to delay the initialization of the mmemory region until realize.

I think a nice fix would be to make it_shift as memory region mutator and allow it to be set after initialization.

b) There's some duplication in MemoryRegions with respect to QOM. Memory regions want to have a name but with QOM they'll be addressable via a path. I go back and forth about how aggressively we want to refactor MemoryRegions.

If someone wants to spend some time converting MemoryRegion to QOM, that would certainly be helpful. So far, I've been avoiding it but we'll eventually need to do it.

Regards,

Anthony Liguori

Reply via email to