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