From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sn97r-0006yB-Ks for qemu-devel@nongnu.org; Fri, 06 Jul 2012 10:03:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sn97c-0001Fq-Sr for qemu-devel@nongnu.org; Fri, 06 Jul 2012 10:03:15 -0400 Received: from cantor2.suse.de ([195.135.220.15]:51900 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sn97c-0001Ff-JP for qemu-devel@nongnu.org; Fri, 06 Jul 2012 10:03:00 -0400 Message-ID: <4FF6F00F.50108@suse.de> Date: Fri, 06 Jul 2012 16:02:55 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1341507652-22155-1-git-send-email-peter.maydell@linaro.org> <1341507652-22155-2-git-send-email-peter.maydell@linaro.org> <4FF6ECC8.9000100@suse.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/6] hw/arm_boot.c: Make ram_size a target_phys_addr_t List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Crosthwaite , Peter Maydell , qemu-devel@nongnu.org, patches@linaro.org Am 06.07.2012 15:54, schrieb Alexander Graf: >=20 > On 06.07.2012, at 15:48, Andreas F=E4rber wrote: >=20 >> Am 05.07.2012 19:00, schrieb Peter Maydell: >>> Make the RAM size in arm_boot_info a target_phys_addr_t so >>> it can express RAM sizes up to the limit imposed by the >>> physical address size. >>> >>> Signed-off-by: Peter Maydell >>> --- >>> hw/arm-misc.h | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/hw/arm-misc.h b/hw/arm-misc.h >>> index 1f96229..c313027 100644 >>> --- a/hw/arm-misc.h >>> +++ b/hw/arm-misc.h >>> @@ -25,7 +25,7 @@ qemu_irq *armv7m_init(MemoryRegion *address_space_m= em, >>> >>> /* arm_boot.c */ >>> struct arm_boot_info { >>> - int ram_size; >>> + target_phys_addr_t ram_size; >>> const char *kernel_filename; >>> const char *kernel_cmdline; >>> const char *initrd_filename; >> >> Didn't we conclude in lengthy and emotional discussions that int64_t w= as >> the best compromise to solve the highbank and pseries image loading is= sues? >> >> What I still dislike about target_phys_addr_t is that "ram_size" is no= t >> an address but a size. >=20 > But isn't MAX(size) always defined to be smaller than or equal to MAX(a= ddr)? So target_phys_addr_t is _always_ a type that is big enough to hold= the information. I'm not disputing that. If you do typedef target_phys_addr_t/* or whatever */ target_phys_size_t; target_phys_size_t ram_size; then I'm happy as well, I just dislike writing target_phys_addr_t size. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg