From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrTCF-0004S3-VK for qemu-devel@nongnu.org; Mon, 02 Jun 2014 10:26:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WrTCA-0003RV-LK for qemu-devel@nongnu.org; Mon, 02 Jun 2014 10:26:43 -0400 Received: from mail-la0-f47.google.com ([209.85.215.47]:43719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrTCA-0003Qn-FZ for qemu-devel@nongnu.org; Mon, 02 Jun 2014 10:26:38 -0400 Received: by mail-la0-f47.google.com with SMTP id pn19so2635388lab.34 for ; Mon, 02 Jun 2014 07:26:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Peter Maydell Date: Mon, 2 Jun 2014 15:26:17 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH memory v3 0/9] Memory Region QOMification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Paolo Bonzini , QEMU Developers , =?UTF-8?Q?Andreas_F=C3=A4rber?= On 2 June 2014 05:13, Peter Crosthwaite 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