[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH memory v3 0/9] Memory Region QOMification
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH memory v3 0/9] Memory Region QOMification |
Date: |
Mon, 2 Jun 2014 15:26:17 +0100 |
On 2 June 2014 05:13, Peter Crosthwaite <address@hidden> 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
- [Qemu-devel] [PATCH memory v3 2/9] qom: object: Ignore refs/unrefs of NULL, (continued)
- [Qemu-devel] [PATCH memory v3 2/9] qom: object: Ignore refs/unrefs of NULL, Peter Crosthwaite, 2014/06/02
- [Qemu-devel] [PATCH memory v3 3/9] qom: Publish object_resolve_link, Peter Crosthwaite, 2014/06/02
- [Qemu-devel] [PATCH memory v3 4/9] memory: Coreify subregion add functionality, Peter Crosthwaite, 2014/06/02
- [Qemu-devel] [PATCH memory v3 5/9] memory: MemoryRegion: factor out memory region re-adder, Peter Crosthwaite, 2014/06/02
- [Qemu-devel] [PATCH memory v3 6/9] memory: MemoryRegion: QOMify, Peter Crosthwaite, 2014/06/02
- [Qemu-devel] [PATCH memory v3 7/9] memory: MemoryRegion: Add container and addr props, Peter Crosthwaite, 2014/06/02
- [Qemu-devel] [PATCH memory v3 8/9] memory: MemoryRegion: Add may-overlap and priority props, Peter Crosthwaite, 2014/06/02
- [Qemu-devel] [PATCH memory v3 9/9] memory: MemoryRegion: Add size property, Peter Crosthwaite, 2014/06/02
- Re: [Qemu-devel] [PATCH memory v3 0/9] Memory Region QOMification,
Peter Maydell <=