Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Mark Cave-Ayland]

On 30/04/12 15:39, Peter Maydell wrote:

> > Right I think I'm starting to understand this now - in which case it becomes
> > a matter of just copying a handful of lines within sun4m which is more
> > bearable.
> >
> > In your view, would a suitable fix be to change dma_memory_read,
> > dma_memory_write, dma_opaque, it_shift and dma_enabled to be qdev properties
> > and modify esp_init() to return the qdev reference so they can be set by the
> > caller?
>
> They should be some kind of qdev property, probably. Since you can't
> change a property after the qdev_init there's not much point changing
> esp_init to return the DeviceState*, though.

In the meantime I've found a bit of reference documentation related to 
QOM and properties here: http://wiki.qemu.org/Features/QOM.

> (Disclaimer: I'm not sure what the best QOM/qdev practice is for "here
> is a set of function pointers". In my ideal world this would be done
> by setting a single strongly typed qdev property which encapsulates
> the idea of "here is a connection into which you can plug something
> that satisfies this dma read/write API".)

Note that if properties can't be set by the caller after construction, 
then I'm effectively going to have to copy the entire esp_init() 
function; so until the QOM magic happens to allow plugging things into 
arbitrary buses, I might as well just keep a copy in sun4m.c with my 
local modifications as sun4_esp_init() and be done with it. Slightly 
frustrating, but I think that's going to be the easiest solution for the 
moment.


ATB,

Mark.