From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S77lN-0000fP-Pt for qemu-devel@nongnu.org; Mon, 12 Mar 2012 12:07:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S77ki-000300-PO for qemu-devel@nongnu.org; Mon, 12 Mar 2012 12:06:16 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43775 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S77ki-0002t4-Ex for qemu-devel@nongnu.org; Mon, 12 Mar 2012 12:05:40 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Alexander Graf In-Reply-To: Date: Mon, 12 Mar 2012 17:04:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <202FDDBF-BB38-4B8C-86BA-7E8337E107AF@suse.de> References: <1331225951-31306-1-git-send-email-mark.langsdorf@calxeda.com> <4F5A0288.6090809@calxeda.com> <9A556F7F-2721-4D51-80D2-8B9571E4EC0F@suse.de> <4F5A06C8.7020903@calxeda.com> <88D21EA9-1000-48DB-9D7A-437622BE8745@suse.de> <4F5A1378.5040909@suse.de> <4F5A503D.2090304@suse.de> <4F5B6069.404@suse.de> Subject: Re: [Qemu-devel] [PATCH] use an unsigned long for the max_sz parameter in load_image_targphys List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Peter Maydell , Mark Langsdorf , Stefan Weil , "qemu-devel@nongnu.org" , Erik Blake , =?iso-8859-1?Q?Andreas_F=E4rber?= , David Gibson On 12.03.2012, at 16:53, Markus Armbruster wrote: > Peter Maydell writes: >=20 > [...] >> Putting a "restrict to INT_MAX" in the highbank code is definitely >> wrong (not least because passing values to load_image_targphys isn't >> the only thing we use that field in arm_boot_info for!) >> The ARM boot code needs updating because it shouldn't be >> using 'int' for arm_boot_info.ram_size, and using target_phys_addr_t >> the same as we do for initrd_size is the obvious thing. I have no >> particular objection to having some new target_phys_size_t or = whatever, >> and I could be persuaded that we should follow the memory API in >> using uint64_t for sizes, but it needs to be a type that either = follows >> guest phys addr restrictions or a fixed-width type which we have = decreed >> is always large enough, >=20 > There is already a type that is defined to be wide enough for any = object > size: size_t. >=20 >> not a type which varies based on host = properties. >=20 > To be honest, the whole debate feels like bikeshedding to me. Yes, > load_image_targphys()'s argument max_sz is the size of a slice of = guest > memory. It's also the size of a host object, allocated with = g_malloc0() > in rom_add_file(). It's also the size of a disk file. >=20 > I'd make it size_t and be done with it. If you absolutely must > overengineer things, go ahead and create a new type for target sizes. = I > doubt making it wider than size_t will work in practice without a lot = of > hoop jumping, though. I agree. Let's end this discussion and use the biggest variable type we = support for addresses: uint64_t. That way we have host independent = predictability, but don't use _addr_t types which Andreas seems to = dislike. Alex