From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S77tc-0001YV-Fm for qemu-devel@nongnu.org; Mon, 12 Mar 2012 12:14:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S77tW-0006Pu-3c for qemu-devel@nongnu.org; Mon, 12 Mar 2012 12:14:52 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44436 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S77tV-0006Pk-Qf for qemu-devel@nongnu.org; Mon, 12 Mar 2012 12:14:46 -0400 Message-ID: <4F5E20F4.5010609@suse.de> Date: Mon, 12 Mar 2012 17:14:44 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 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> <202FDDBF-BB38-4B8C-86BA-7E8337E107AF@suse.de> In-Reply-To: <202FDDBF-BB38-4B8C-86BA-7E8337E107AF@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Alexander Graf Cc: Peter Maydell , Mark Langsdorf , Stefan Weil , "qemu-devel@nongnu.org" , Markus Armbruster , Erik Blake , David Gibson Am 12.03.2012 17:04, schrieb Alexander Graf: >=20 > On 12.03.2012, at 16:53, Markus Armbruster wrote: >=20 >> Peter Maydell writes: >> >> [...] >>> 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 whateve= r, >>> 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 follo= ws >>> guest phys addr restrictions or a fixed-width type which we have decr= eed >>> is always large enough, >> >> There is already a type that is defined to be wide enough for any obje= ct >> size: size_t. >> >>> not a type which varies based on host properti= es. >> >> 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 gues= t >> 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. >> >> 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. >=20 > 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 predi= ctability, but don't use _addr_t types which Andreas seems to dislike. Fine with me. 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