From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjAKx-0000qq-NP for qemu-devel@nongnu.org; Tue, 19 Jul 2011 09:27:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjAKv-0001dN-Bc for qemu-devel@nongnu.org; Tue, 19 Jul 2011 09:27:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjAKu-0001d2-LU for qemu-devel@nongnu.org; Tue, 19 Jul 2011 09:27:45 -0400 Message-ID: <4E25864A.10905@redhat.com> Date: Tue, 19 Jul 2011 16:27:38 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1310901265-32051-1-git-send-email-avi@redhat.com> <4E2581F4.5090004@codemonkey.ws> In-Reply-To: <4E2581F4.5090004@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 07/19/2011 04:09 PM, Anthony Liguori wrote: > On 07/17/2011 06:13 AM, Avi Kivity wrote: >> New in this version: >> MemoryRegionOps gained .old_mmio and .old_portio members, which allow >> reusing old-style callbacks with the new API. All uses were >> converted, >> except for eepro100.c, which uses the same MemoryRegionOps for both >> portio and mmio. Some intermediate patches do introduce dispatching >> callbacks, but they are removed later. >> >> Caveats: >> - some devices still grab a global memory region instead of inheriting >> it from their bus. Seen in the code as #include "exec-memory.h" > > Could you write up a quick document on how to use this new api for docs/? Sure. It's pretty simple. > > There's bits I don't like about the interface Which bits are these? > but I think it's a huge improvement over what we have now so I'm > inclined to commit once it includes documentation. > My problem is that to start leveraging it, everything must flow through it. There are still several hundred call sites that are unconverted. One option is to invert the relationship between ram_addr_t and MemoryRegion - implement the former in terms of the latter. That only works for uses which don't invoke IO_MEM_UNASSIGNED or address arithmetic. -- error compiling committee.c: too many arguments to function