From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:34947)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1QoKRh-0001i1-HT
	for qemu-devel@nongnu.org; Tue, 02 Aug 2011 15:16:06 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1QoKRg-00005Q-Bk
	for qemu-devel@nongnu.org; Tue, 02 Aug 2011 15:16:05 -0400
Received: from mx1.redhat.com ([209.132.183.28]:63838)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1QoKRg-00005B-2a
	for qemu-devel@nongnu.org; Tue, 02 Aug 2011 15:16:04 -0400
Message-ID: <4E384CEE.7060000@redhat.com>
Date: Tue, 02 Aug 2011 22:15:58 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <CAFEAcA9P=1pcjt8+eZQeD53Vbn9rnJGsC916e7+nP07B=TDoyw@mail.gmail.com>
	<4E381EA7.2070809@redhat.com>
	<CAFEAcA9djGhDKE_S4cQg+Jtj6Spy3p+7uUMNeJDE4ijzoYWxzA@mail.gmail.com>
	<4E383CE5.4010405@siemens.com>
In-Reply-To: <4E383CE5.4010405@siemens.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] modelling omap_gpmc with the hierarchical memory
	API
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, QEMU Developers <qemu-devel@nongnu.org>

On 08/02/2011 09:07 PM, Jan Kiszka wrote:
> >>
> >>
> >>   system_memory
> >>      |
> >>      +--- cs_region-0
> >>              |
> >>              +--- device-connected-to-that-region
> >>
> >>  cs-region-0 will clip anything under it.
> >
> >  OK, and when we change the size of CS0 we delete the container
> >  region, create a new one of the new size and reconnect the
> >  device-region to the new container? That's a bit clumsy but it
> >  will work.
>
> That's why I was asking for a memory_region_update service + region
> description via some struct, not (only) via function arguments.

Maybe we can do something like

   memory_region_init(&myregion, (MemoryDesc) {
       .size = blah,
       .foo = bar,
       })

and use the same structure for updates.

>  And that's why we need GPIO/IRQ services at qdev level, not exclusively
>  for sysbus club members.

Is there any sysbus thing which doesn't need to become a qdev thing?  I'd guess that the only sysbus property that doesn't need to become part of qdev is its singletonness.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.