From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMjGR-0008VV-3z for qemu-devel@nongnu.org; Wed, 18 May 2011 12:06:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMjGP-0005Ui-Va for qemu-devel@nongnu.org; Wed, 18 May 2011 12:06:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMjGP-0005UV-MF for qemu-devel@nongnu.org; Wed, 18 May 2011 12:06:21 -0400 Message-ID: <4DD3EE75.70408@redhat.com> Date: Wed, 18 May 2011 19:06:13 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD3E0E5.2030700@codemonkey.ws> <4DD3EA2F.4080200@mail.berlios.de> In-Reply-To: <4DD3EA2F.4080200@mail.berlios.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel On 05/18/2011 06:47 PM, Stefan Weil wrote: >> I'm not a fan of having per-access type function pointers. > > > Do you think of something like these declaration: > > typedef uint64_t (*MemoryReadFunc)(MemoryRegion *mr, > target_phys_addr_t addr, size_t size); > typedef void (*MemoryWriteFunc)(MemoryRegion *mr, target_phys_addr_t > addr, uint64_t data, size_tsize); > > For 32 bit host / target, this would mean some unnecessary overhead. Frankly, the overhead is pretty low. I think we can neglect it. > > What about passing values by address: > > typedef void (*MemoryReadFunc)(MemoryRegion *mr, target_phys_addr_t > addr, void *data, size_t size); > typedef void (*MemoryWriteFunc)(MemoryRegion *mr, target_phys_addr_t > addr, const void *data, size_t size); Those void *s will be quite annoying. Especially on hosts which don't allow misaligned data, you'll never know how to reference them. > > If we keep per-access type function pointers, they should use > individual prototypes > for the different access types: > > typedef uint8_t (*MemoryReadbFunc)(MemoryRegion *mr, > target_phys_addr_t addr); > typedef uint16_t (*MemoryReadwFunc)(MemoryRegion *mr, > target_phys_addr_t addr); > typedef uint32_t (*MemoryReadlFunc)(MemoryRegion *mr, > target_phys_addr_t addr); > typedef uint64_t (*MemoryReadllFunc)(MemoryRegion *mr, > target_phys_addr_t addr); > ... I prefer having size as an argument. Something else I though about: void memory_region_set_access_sizes(MemoryRegion *mr, int min, int max); if, for example, min=2 and max=4, then byte accesses will be emulated as word accesses (RMW for writes) and quad accesses will be emulated as two long accesses. So a device that emulates 32-bit registers can set min=max=4 and get all the other sizes for free. -- error compiling committee.c: too many arguments to function