From: Eric Blake <eblake@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Anthony Liguori" <aliguori@us.ibm.com>,
patches@linaro.org, qemu-trivial@nongnu.org,
"John Rigby" <john.rigby@linaro.org>,
qemu-devel@nongnu.org, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line
Date: Mon, 20 May 2013 10:57:23 -0600 [thread overview]
Message-ID: <519A55F3.8090101@redhat.com> (raw)
In-Reply-To: <CAFEAcA_VhTQvsE-XYa4pFZBXJq1kyMeOTp8ccxcLtriQJre+OA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]
On 05/20/2013 10:47 AM, Peter Maydell wrote:
> On 20 May 2013 17:41, Eric Blake <eblake@redhat.com> wrote:
>> Yep, that raises (once again) the question of dynamic introspection -
>> there's a difference between the maximum amount of information known at
>> compile time, and the subset of enum values that are actually usable at
>> runtime. This list is static (all known architectures)
>
> It's not really static though for practical purposes. The user
> still has to be able to cope with "I know about architecture foo
> but it's not in the list" (if talking to an older qemu) or
> "the list contains architecture bar which I don't know about"
> (if talking to a newer qemu). I think the only thing we really
> need to avoid is changing the name of an existing architecture?
I'm not talking about keeping the enum static as in unchanging in all
future qemu releases, so much as static in that "at the time qemu was
compiled, this was the list of architectures qemu knew about". But what
good does it do to know what other architectures the compile-time qemu
knew about, when what we really care about is what does THIS qemu binary
emulate. And Paolo raised the point that what we really care about is
static-per-binary - that is, each binary supports exactly one
architecture (unless you are doing a LOT of work to support multi-arch
emulation from a single binary!).
Changing the name of an architecture would be reflected by having a
different qemu-FOO binary name, right? If that's the case, then
introspection of which architectures are supported is done by listing
all the matches to qemu-* in the directory where binaries are installed,
and we don't need a QMP enum duplicating what the file system already
tells us.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]
next prev parent reply other threads:[~2013-05-20 16:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-20 16:21 [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line Peter Maydell
2013-05-20 16:35 ` Paolo Bonzini
2013-05-20 16:38 ` Peter Maydell
2013-05-20 17:14 ` Paolo Bonzini
2013-05-22 13:15 ` Anthony Liguori
2013-05-22 13:50 ` Andreas Färber
2013-05-22 14:28 ` Anthony Liguori
2013-05-22 14:34 ` [Qemu-devel] New targets (was: [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line) Andreas Färber
2013-05-22 14:48 ` Anthony Liguori
2013-05-22 15:33 ` Peter Maydell
2013-05-22 16:10 ` Anthony Liguori
2013-05-22 13:51 ` [Qemu-devel] [PATCH] qapi-schema.json: Reformat TargetType enum to one-per-line Peter Maydell
2013-05-22 14:29 ` Anthony Liguori
2013-05-22 14:38 ` Paolo Bonzini
2013-05-24 21:38 ` [Qemu-devel] [libvirt] " Eric Blake
2013-05-25 9:18 ` Peter Maydell
2013-05-25 12:31 ` Andreas Färber
2013-05-20 16:41 ` [Qemu-devel] " Eric Blake
2013-05-20 16:47 ` Peter Maydell
2013-05-20 16:57 ` Eric Blake [this message]
2013-05-20 17:05 ` Paolo Bonzini
2013-05-22 13:12 ` Anthony Liguori
2013-05-22 13:38 ` Peter Maydell
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=519A55F3.8090101@redhat.com \
--to=eblake@redhat.com \
--cc=afaerber@suse.de \
--cc=aliguori@us.ibm.com \
--cc=john.rigby@linaro.org \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@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).