From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNLyY-0004KL-Mq for qemu-devel@nongnu.org; Fri, 20 May 2011 05:26:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNLyX-0001RP-KZ for qemu-devel@nongnu.org; Fri, 20 May 2011 05:26:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49677) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNLyX-0001Qd-DP for qemu-devel@nongnu.org; Fri, 20 May 2011 05:26:29 -0400 Message-ID: <4DD633BC.8020801@redhat.com> Date: Fri, 20 May 2011 12:26:20 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1305814352-15044-1-git-send-email-avi@redhat.com> <1305814352-15044-2-git-send-email-avi@redhat.com> <4DD585CA.4070102@mail.berlios.de> In-Reply-To: <4DD585CA.4070102@mail.berlios.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v1] Add declarations for hierarchical memory region API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 05/20/2011 12:04 AM, Stefan Weil wrote: > Am 19.05.2011 16:12, schrieb Avi Kivity: >> The memory API separates the attributes of a memory region (its size, >> how >> reads or writes are handled, dirty logging, and coalescing) from >> where it >> is mapped and whether it is enabled. This allows a device to configure >> a memory region once, then hand it off to its parent bus to map it >> according >> to the bus configuration. >> >> Hierarchical registration also allows a device to compose a region >> out of >> a number of sub-regions with different properties; for example some >> may be >> RAM while others may be MMIO. >> --- /dev/null >> +++ b/memory.h >> @@ -0,0 +1,142 @@ >> +#ifndef MEMORY_H >> +#define MEMORY_H >> + >> +#include >> +#include > > stdbool.h is already included in qemu-common.h, > stdint.h (indirectly) too. > > Therefore both include statements can be removed. We shouldn't rely on indirect includes, it makes updating headers very hard. Each header should #include what it directly needs and no more. >> +typedef struct CoalescedMemoryRange CoalescedMemoryRange; >> + >> +struct CoalescedMemoryRange { >> + target_phys_addr_t start; >> + target_phys_addr_t size; >> + QTAILQ_ENTRY(coalesced_ranges) link; >> +}; >> + >> +struct MemoryRegion { >> + /* All fields are private - violators will be prosecuted */ > > Is it possible to move this private declaration into the implementation > file (or a private header file if the declaration is needed by more than > one file)? No, the structure size is needed by clients. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.