From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnGB8-0004tz-Bh for qemu-devel@nongnu.org; Thu, 13 Jun 2013 18:39:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UnGB7-0007ji-Di for qemu-devel@nongnu.org; Thu, 13 Jun 2013 18:39:38 -0400 Received: from mail-qc0-x236.google.com ([2607:f8b0:400d:c01::236]:43418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UnGB7-0007je-9k for qemu-devel@nongnu.org; Thu, 13 Jun 2013 18:39:37 -0400 Received: by mail-qc0-f182.google.com with SMTP id e10so3817428qcy.41 for ; Thu, 13 Jun 2013 15:39:36 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51BA4A25.6070806@redhat.com> Date: Thu, 13 Jun 2013 18:39:33 -0400 From: Paolo Bonzini MIME-Version: 1.0 References: <20130613125906.GA32223@redhat.com> <51BA41F9.4040801@redhat.com> <20130613222646.GA12654@redhat.com> In-Reply-To: <20130613222646.GA12654@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] exec: move io_mem_read/write to memory.h List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Anthony Liguori , qemu-devel@nongnu.org Il 13/06/2013 18:26, Michael S. Tsirkin ha scritto: > On Thu, Jun 13, 2013 at 06:04:41PM -0400, Paolo Bonzini wrote: >> Il 13/06/2013 08:59, Michael S. Tsirkin ha scritto: >>> implementation is in memory.c, move function >>> to match. This allows use from places that >>> don't pull in exec-all.h >> >> But they shouldn't be used. :) >> >> Everything except the current users (TCG, and address_space_rw and >> friends) should go through exec.c. >> >> Paolo > > OK but still. It's an interface that memory.c exports. > > If you want to mark it as internal, make this clear > in the name but IMO it's a bad idea to force > everyone to use grep to find where the implementation > of each function is. Yes, I agree. To add to the mess, io_mem_{read,write} are just old-fashioned names for (static) memory_region_dispatch_{read,write}. I need to understand whether/how the per-arch calls to softmmu_template.h could be moved to exec.c. Then io_mem_{read,write} can just disappear, and memory_region_dispatch_{read,write} can move to memory-internal.h. Paolo >>> Signed-off-by: Michael S. Tsirkin >>> --- >>> >>> include/exec/exec-all.h | 5 ----- >>> include/exec/memory.h | 5 +++++ >>> 2 files changed, 5 insertions(+), 5 deletions(-) >>> >>> diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h >>> index 6362074..28cb37d 100644 >>> --- a/include/exec/exec-all.h >>> +++ b/include/exec/exec-all.h >>> @@ -367,11 +367,6 @@ bool is_tcg_gen_code(uintptr_t pc_ptr); >>> #if !defined(CONFIG_USER_ONLY) >>> >>> struct MemoryRegion *iotlb_to_region(hwaddr index); >>> -uint64_t io_mem_read(struct MemoryRegion *mr, hwaddr addr, >>> - unsigned size); >>> -void io_mem_write(struct MemoryRegion *mr, hwaddr addr, >>> - uint64_t value, unsigned size); >>> - >>> void tlb_fill(CPUArchState *env1, target_ulong addr, int is_write, int mmu_idx, >>> uintptr_t retaddr); >>> >>> diff --git a/include/exec/memory.h b/include/exec/memory.h >>> index 9e88320..edeb1f2 100644 >>> --- a/include/exec/memory.h >>> +++ b/include/exec/memory.h >>> @@ -888,6 +888,11 @@ void address_space_unmap(AddressSpace *as, void *buffer, hwaddr len, >>> int is_write, hwaddr access_len); >>> >>> >>> +uint64_t io_mem_read(struct MemoryRegion *mr, hwaddr addr, >>> + unsigned size); >>> +void io_mem_write(struct MemoryRegion *mr, hwaddr addr, >>> + uint64_t value, unsigned size); >>> + >>> #endif >>> >>> #endif >>> > >