On 2 June 2014 05:13, Peter Crosthwaite <peter.crosthwa...@xilinx.com> wrote: > This patch series QOMifies Memory regions. This is the Memory API > specific subset of patches forming part of the Memory/GPIO/Sysbus > QOMification. > > I think Paolo already has P1 enqeued. Including for ease of review. > some QOM patches in P2-3 that cut down on later boilerplate. TBH I can > live without them, if they not liked but they make life better IMO. > > For fuller context please see: > > http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg03265.html
So could you sketch an example of how this would work (for board model construction, not command line arguments)? I'm guessing something like: dev = qdev_create(NULL, "my-device"); object_property_set_something(OBJECT(dev), "container", my_memregion); object_property_set_uint64(OBJECT(dev), "addr", 0x40000); qdev_init_nofail(dev); Code wise it looks OK but it feels oddly back-to-front to put a subregion into a container by setting properties on the subregion. At least personally I think of the mapping operation as an operation on the container that says "put this object X in at address Y", not as an operation on the object X that says "your container is C and you're at address Y in it". But I can see how this approach pretty much falls out of our current MemoryRegion data structure, so perhaps I just need to reverse the orientation of my brain... (Also it doesn't make sense to set only one of the (container,address) property pair, but I guess two properties which we can already handle makes more sense than having one which would need a custom parser of some kind.) The other question is how you see this fitting into our other use-case for passing MemoryRegions around: what would the code for passing a container region to a memory transaction source like a CPU object look like? thanks -- PMM