From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qqftf-0006cR-CR for qemu-devel@nongnu.org; Tue, 09 Aug 2011 02:34:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qqfte-0001Tr-9L for qemu-devel@nongnu.org; Tue, 09 Aug 2011 02:34:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qqfte-0001Tm-2o for qemu-devel@nongnu.org; Tue, 09 Aug 2011 02:34:38 -0400 Message-ID: <4E40D4F7.3080702@redhat.com> Date: Tue, 09 Aug 2011 09:34:31 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1312823229-12822-1-git-send-email-avi@redhat.com> <1312823229-12822-10-git-send-email-avi@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 09/24] omap_gpmc/nseries/tusb6010: convert to memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 08/08/2011 08:43 PM, Peter Maydell wrote: > On 8 August 2011 18:06, Avi Kivity wrote: > > Somewhat clumsy since it needs a variable sized region. > > > @@ -119,7 +120,7 @@ void omap_sdrc_reset(struct omap_sdrc_s *s); > > struct omap_gpmc_s; > > struct omap_gpmc_s *omap_gpmc_init(target_phys_addr_t base, qemu_irq irq); > > void omap_gpmc_reset(struct omap_gpmc_s *s); > > -void omap_gpmc_attach(struct omap_gpmc_s *s, int cs, int iomemtype, > > +void omap_gpmc_attach(struct omap_gpmc_s *s, int cs, MemoryRegion *iomem, > > void (*base_upd)(void *opaque, target_phys_addr_t new), > > void (*unmap)(void *opaque), void *opaque); > > I have a pile of omap_gpmc patches almost ready to submit which > are mostly waiting on my figuring out how to get them to work > with the new memory API. > > In particular I think this is wrong -- omap_gpmc_attach should > just take a MemoryRegion*, and there should be standard APIs > for "resize this memory region" and "unmap this memory region", > [we have the latter but not the former currently], at which point > there's no need to pass in base_upd or unmap function pointers. > I agree we need better support for this in the core. But I'm limiting core updates so I can continue to convert users, without which the entire effort is useless, and so I can collect additional requirements. Also, my patchset focuses on mechanical transformations. It is already risky enough in terms of regressions, I'm not going to rewrite/improve all of qemu; if you want those callbacks removed, you will have to remove them yourself. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.