From: "Andreas Färber" <afaerber@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Alexander Graf <agraf@suse.de>,
Mark Langsdorf <mark.langsdorf@calxeda.com>,
Stefan Weil <sw@weilnetz.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
Erik Blake <eblake@redhat.com>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH] use an unsigned long for the max_sz parameter in load_image_targphys
Date: Mon, 12 Mar 2012 17:12:09 +0100 [thread overview]
Message-ID: <4F5E2059.7040606@suse.de> (raw)
In-Reply-To: <CAFEAcA9Wn1CQ0L=1UwkwiPLLc1iEVJegerZZUKWUhuAP4JVfjg@mail.gmail.com>
Am 10.03.2012 16:27, schrieb Peter Maydell:
> On 10 March 2012 14:08, Andreas Färber <afaerber@suse.de> wrote:
>> Am 10.03.2012 14:51, schrieb Peter Maydell:
>>> "Length of a block of memory on the guest" is what I meant.
>>> What you need is "an integer type large enough to hold the
>>> difference between two guest pointer values". The size of
>>> that type should depend only on the guest config, not on the
>>> host, so 'unsigned long', 'size_t', 'off_t' etc are all wrong.
>>
>> Your view is very ARM-centric.
>
> I don't understand this remark. Nothing about the above explanation
> is ARM-centric
[snip]
ARM-centric is that you and Mark are trying to solve the issue of ARM
boards supplying guest RAM size as limit for image loading. I'm saying
many other boards don't have that issue because they're using a constant
size value way below any theoretical limit.
Now the theory behind this part of the thread is about what type to use
for a delta vs. absolute value. If you subtract void * from void * you
get a ptrdiff_t. Similarly in C# or Java or whatever subtracing two Time
objects will return a TimeDiff object or so. Whether you specify a
temperature in degrees Celsius or Kelvin, the difference is in degrees.
In that same spirit I'm opposed to using target_phys_addr_t for a size
(delta) between two addresses. HTE.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2012-03-12 16:12 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-08 16:59 [Qemu-devel] [PATCH] use an unsigned long for the max_sz parameter in load_image_targphys Mark Langsdorf
2012-03-08 17:56 ` Eric Blake
2012-03-08 18:13 ` Mark Langsdorf
2012-03-09 9:25 ` Markus Armbruster
2012-03-09 13:15 ` Mark Langsdorf
2012-03-09 13:21 ` Alexander Graf
2012-03-09 13:34 ` Mark Langsdorf
2012-03-09 13:50 ` Alexander Graf
2012-03-09 13:58 ` Peter Maydell
2012-03-09 14:28 ` Andreas Färber
2012-03-09 17:11 ` Peter Maydell
2012-03-09 18:47 ` Andreas Färber
2012-03-09 19:04 ` Alexander Graf
2012-03-10 6:24 ` Markus Armbruster
2012-03-10 14:22 ` Andreas Färber
2012-03-10 13:51 ` Peter Maydell
2012-03-10 14:08 ` Andreas Färber
2012-03-10 15:27 ` Peter Maydell
2012-03-12 15:28 ` Mark Langsdorf
2012-03-12 15:53 ` Markus Armbruster
2012-03-12 16:04 ` Alexander Graf
2012-03-12 16:09 ` Peter Maydell
2012-03-12 16:14 ` Andreas Färber
2012-03-12 16:12 ` Andreas Färber [this message]
2012-03-09 14:17 ` Markus Armbruster
2012-03-09 14:52 ` Mark Langsdorf
2012-03-09 15:12 ` Markus Armbruster
2012-03-09 14:01 ` [Qemu-devel] [PATCH v2] " Mark Langsdorf
2012-03-09 14:31 ` Markus Armbruster
2012-03-09 15:57 ` [Qemu-devel] [PATCH] arm highbank: force ramsize to INT_MAX when loading Mark Langsdorf
2012-03-09 16:13 ` Peter Maydell
2012-03-09 16:40 ` Mark Langsdorf
2012-03-09 18:22 ` Alexander Graf
2012-03-09 19:03 ` Andreas Färber
2012-03-09 19:21 ` Alexander Graf
2012-03-12 16:33 ` [Qemu-devel] [PATCH v3] use an uint64_t for the max_sz parameter in load_image_targphys Mark Langsdorf
2012-03-12 16:47 ` Andreas Färber
2012-03-12 17:13 ` Peter Maydell
2012-03-12 17:23 ` Mark Langsdorf
2012-03-12 16:58 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F5E2059.7040606@suse.de \
--to=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=armbru@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=eblake@redhat.com \
--cc=mark.langsdorf@calxeda.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=sw@weilnetz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).