From: Laszlo Ersek <lersek@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org, libvir-list@redhat.com,
"Daniel P. Berrange" <berrange@redhat.com>,
Alexander Graf <agraf@suse.de>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
David Gibson <dgibson@redhat.com>, Eric Blake <eblake@redhat.com>,
Gary Ching-Pang Lin <glin@suse.com>,
Kashyap Chamarthy <kchamart@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Michael Roth <mdroth@linux.vnet.ibm.com>,
Michal Privoznik <mprivozn@redhat.com>,
Peter Krempa <pkrempa@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"
Date: Tue, 10 Apr 2018 11:16:01 +0200 [thread overview]
Message-ID: <dc439111-4161-96e6-5b45-4dcee886427d@redhat.com> (raw)
In-Reply-To: <20180410062754.eohou7i7chf6w65j@sirius.home.kraxel.org>
On 04/10/18 08:27, Gerd Hoffmann wrote:
> Hi,
>
>> - I considered adding wildcards (say, blacklist "all" i440fx machtypes,
>> present and future, for SMM-requiring OVMF builds), but then you get
>> into version sorting and similar mess. I considered fnmatch() --
>> basically simple ? and * wildcards -- but that's not expressive enough.
>
> I'd suggest whitelist with wildcards. So the smm builds would get
> "pc-q35-*".
>
> libvirt knows about aliases, so it should be able to handle the "q35"
> shortcut like "pc-q35-${latest}".
>
> Or do you see another issue?
Well, one issue I see is version sorting; I should say "Q35 but no
earlier than 2.4", and lexicographically, "2.11" sorts before "2.4".
Anyway (also asking for Thomas's input here): if we run with your idea
to refer to exact mapping methods / firmware *implementation* types that
we know libvirt implements / supports as a "white box", do we still deem
machine type identification necessary? Because, libvirt already knows
(for example) that "ovmf_smm" requires pc-q35-2.4 or later. So we just
have to make a *reference* to that knowledge in the JSON file.
And, really, this seems to reinforce my point that the schema should
live in the libvirtd tree, not in the QEMU tree. In that case, perhaps
it would be a better fit to work with an XSD, and firmware packages
should install XML files? Personally I'm a lot more attracted to
XML/XSD; I think the tooling is better too. I just don't see how QEMU is
involved.
Opinions please :)
Thanks!
Laszlo
next prev parent reply other threads:[~2018-04-10 9:16 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-07 0:01 [Qemu-devel] [qemu RFC] qapi: add "firmware.json" Laszlo Ersek
2018-04-09 7:26 ` Thomas Huth
2018-04-09 8:19 ` Gerd Hoffmann
2018-04-09 16:50 ` Laszlo Ersek
2018-04-10 6:18 ` Gerd Hoffmann
2018-04-10 9:09 ` Laszlo Ersek
2018-04-10 7:33 ` Thomas Huth
2018-04-10 9:22 ` Laszlo Ersek
2018-04-10 9:32 ` Thomas Huth
2018-04-10 11:53 ` Laszlo Ersek
2018-04-10 9:09 ` Daniel P. Berrangé
2018-04-09 16:34 ` Laszlo Ersek
2018-04-10 5:59 ` Gerd Hoffmann
2018-04-10 9:07 ` Laszlo Ersek
2018-04-10 9:51 ` Gerd Hoffmann
2018-04-10 9:55 ` Daniel P. Berrangé
2018-04-10 12:04 ` Laszlo Ersek
2018-04-10 7:44 ` Thomas Huth
2018-04-10 8:57 ` Laszlo Ersek
2018-04-10 9:05 ` Daniel P. Berrangé
2018-04-10 9:19 ` Thomas Huth
2018-04-10 11:40 ` Laszlo Ersek
2018-04-09 8:08 ` Thomas Huth
2018-04-09 16:42 ` Laszlo Ersek
2018-04-10 6:27 ` Gerd Hoffmann
2018-04-10 9:16 ` Laszlo Ersek [this message]
2018-04-10 9:23 ` Daniel P. Berrangé
2018-04-10 10:09 ` Paolo Bonzini
2018-04-10 11:46 ` Laszlo Ersek
2018-04-10 9:26 ` Thomas Huth
2018-04-10 11:53 ` Laszlo Ersek
2018-04-10 9:34 ` Daniel P. Berrangé
2018-04-10 11:57 ` Laszlo Ersek
2018-04-09 8:26 ` Gerd Hoffmann
2018-04-09 16:53 ` Laszlo Ersek
2018-04-09 8:49 ` Daniel P. Berrangé
2018-04-09 17:57 ` Laszlo Ersek
2018-04-10 9:18 ` Daniel P. Berrangé
2018-04-10 11:27 ` Laszlo Ersek
2018-04-10 11:34 ` Daniel P. Berrangé
2018-04-10 11:44 ` Laszlo Ersek
2018-04-10 11:50 ` Daniel P. Berrangé
2018-04-10 11:48 ` Peter Maydell
2018-04-10 11:52 ` Daniel P. Berrangé
2018-04-10 10:20 ` Daniel P. Berrangé
2018-04-10 11:03 ` Daniel P. Berrangé
2018-04-10 11:37 ` Gerd Hoffmann
2018-04-10 12:12 ` Laszlo Ersek
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=dc439111-4161-96e6-5b45-4dcee886427d@redhat.com \
--to=lersek@redhat.com \
--cc=agraf@suse.de \
--cc=ard.biesheuvel@linaro.org \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgibson@redhat.com \
--cc=eblake@redhat.com \
--cc=glin@suse.com \
--cc=kchamart@redhat.com \
--cc=kraxel@redhat.com \
--cc=libvir-list@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mprivozn@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pkrempa@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/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).