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: Fri, 09 Mar 2012 19:47:25 +0100 [thread overview]
Message-ID: <4F5A503D.2090304@suse.de> (raw)
In-Reply-To: <CAFEAcA9QxGVCbE1YCiY7RpkOhwVKrAbhcQrvzYw7u+cEz0B7uQ@mail.gmail.com>
Am 09.03.2012 18:11, schrieb Peter Maydell:
> On 9 March 2012 14:28, Andreas Färber <afaerber@suse.de> wrote:
>> No, please. We're describing sizes, not addresses. target_phys_addr_t
>> thus is semantically wrong here. The RAM size is unsigned long IIRC (it
>> is limited by the host's available memory). If you subtract something
>> from a size it remains a size. I had therefore suggested size_t before.
>> I expect sizeof(size_t) >= sizeof(unsigned long).
>
> We're discussing target sizes. size_t might be smaller than
> target_phys_addr_t, so it's also semantically wrong. We don't
> have a target_size_t, though, and I think "use an address
> related type for an offset" is less bad than "use a host
> sized type for a guest sized value".
That is a moot point. There is no such thing as a "target size". The
size is defined by the guest OS, not by the architecture. And it doesn't
matter if the guest OS's size is defined larger than the host's because
we process those files on the host and they must fit into host memory.
So unsigned long would be perfectly fine if ignoring oddball win64.
> Compare the way we use target_phys_addr_t for the offset arguments
> to MemoryRegion read/write functions.
Nobody here has been arguing against using target_phys_addr_t for guest
memory *offsets*.
Actually, the size (1, 2, 4) is an unsigned int there. :) Fine with me.
And due to very similar signed overflow issues with int64_t, 128-bit
integer support was introduced as a workaround. ;)
Anyway, POSIX:2008 says this about sys/types.h:
off_t
Used for file sizes.
size_t
Used for sizes of objects.
ssize_t
Used for a count of bytes or an error indication.
So off_t seems right for get_image_size() although a bit
counter-intuitive. However later is said, "off_t shall be signed integer
types". So on a 32-bit host that does not necessarily help for the case
at hands. (Since get_image_size() gets its value as an off_t though, it
doesn't matter there and improves the 64-bit host case.)
By comparison, "size_t shall be an unsigned integer type" and "The
implementation shall support one or more programming environments in
which the widths of [...] size_t, ssize_t, [...] are no greater than the
width of type long".
So I still think that size_t is our best bet for potentially large sizes
here. Comparison with off_t would cause warnings though...
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-09 18:47 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 [this message]
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
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=4F5A503D.2090304@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).