From: Markus Armbruster <armbru@redhat.com>
To: qemu-devel@nongnu.org
Cc: marcandre.lureau@redhat.com,
Claudio Fontana <claudio.fontana@huawei.com>,
Luiz Capitulino <lcapitulino@redhat.com>
Subject: [Qemu-devel] ivshmem property size should be a size, not a string
Date: Fri, 20 Nov 2015 17:07:08 +0100 [thread overview]
Message-ID: <87si401wpf.fsf@blackfin.pond.sub.org> (raw)
Everybody's favourite device model has "size" property. It's declared
as *string*
DEFINE_PROP_STRING("size", IVShmemState, sizearg),
which gets converted to a size manually in the realize method:
} else if (s->sizearg == NULL) {
s->ivshmem_size = 4 << 20; /* 4 MB default */
} else {
char *end;
int64_t size = qemu_strtosz(s->sizearg, &end);
if (size < 0 || *end != '\0' || !is_power_of_2(size)) {
error_setg(errp, "Invalid size %s", s->sizearg);
return;
}
s->ivshmem_size = size;
}
This is *wrong*. Impact, as far as I can tell:
* -device ivshmem,help shows the property as 'str' instead of 'size'.
Unhelpful, but hardly show-stopper.
* On the command line and in HMP, ivshmem's size is parsed differently
than other size properties. In particular, a number without a suffix
is normally interpreted as bytes, except for ivshmem, where it's
Mebibytes.
Ugly inconsistency, but hardly the only one.
* In QMP, the size must be given as JSON string instead of JSON number,
and size suffixes are accepted. Example: "size": "512k" instead of
"size": 524288.
Right now, this violation of QMP rules is tolerable (barely), because
device_add breaks some of these rules already. However, one goal of
the current work on QAPI is to support a QMP command to plug devices
that doesn't break QMP rules, and then this violation will stand out.
Therefore, I want it fixed now, before ivshmem gets used in anger.
A straight fix of size isn't fully backwards compatible: suffixes no
longer work in QMP, and you need to use an 'M' suffix to get Mebibytes
on command line and HMP.
If that's unacceptable, we'll have to provide a new, fixed property,
and deprecate size.
Opinions?
next reply other threads:[~2015-11-20 16:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-20 16:07 Markus Armbruster [this message]
2015-11-20 16:23 ` [Qemu-devel] ivshmem property size should be a size, not a string Marc-André Lureau
2015-11-20 16:46 ` Eric Blake
2015-11-20 18:06 ` Markus Armbruster
2015-11-20 18:20 ` Marc-André Lureau
2015-11-20 19:39 ` Markus Armbruster
2015-11-20 20:18 ` Marc-André Lureau
2015-11-23 10:19 ` Markus Armbruster
2015-11-23 12:15 ` Marc-André Lureau
2015-11-23 13:25 ` Markus Armbruster
2015-11-23 13:48 ` Marc-André Lureau
2015-11-23 14:08 ` Markus Armbruster
2015-11-23 14:16 ` Marc-André Lureau
2015-11-23 14:46 ` Markus Armbruster
2015-11-23 14:53 ` Marc-André Lureau
2015-11-23 15:17 ` Markus Armbruster
2015-11-23 19:52 ` Eric Blake
2015-11-23 20:19 ` Marc-André Lureau
2015-11-24 9:56 ` Markus Armbruster
2015-11-24 12:23 ` Marc-André Lureau
2015-11-24 13:50 ` Markus Armbruster
2015-11-24 14:23 ` Marc-André Lureau
2015-11-24 15:12 ` Markus Armbruster
2015-11-23 18:22 ` Markus Armbruster
2015-11-23 23:29 ` Andrew James
2015-11-24 9:52 ` Markus Armbruster
2015-11-23 20:57 ` Bruce Rogers
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=87si401wpf.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=claudio.fontana@huawei.com \
--cc=lcapitulino@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).