From: Stefan Hajnoczi <stefanha@gmail.com>
To: Juan Quintela <quintela@redhat.com>
Cc: John Snow <jsnow@redhat.com>, qemu-devel <qemu-devel@nongnu.org>,
kvm-devel <kvm@vger.kernel.org>
Subject: Re: KVM call for agenda for 2020-10-06
Date: Tue, 6 Oct 2020 19:21:29 +0100 [thread overview]
Message-ID: <CAJSP0QVZcEQueXG1gjwuLszdUtXWi1tgB5muLL6QHJjNTOmyfQ@mail.gmail.com> (raw)
In-Reply-To: <20201005144615.GE5029@stefanha-x1.localdomain>
Thank you everyone who joined the call. The meeting notes are below.
Stefan
---
*KVM Community Call - Tue Oct 6th
*Topic: QEMU CLI QAPI conversion
* John Snow's summary of command-line options:
https://docs.google.com/spreadsheets/d/1OJvzDwLpo2XsGytNp9Pr-vYIrb0pWrFKBNPtOyH80ew/edit?usp=sharing
* What is the first milestone?
* Is it QemuOpts for everything? Straight to QAPI? something else?
* Markus: The goal is to represent the configuration interface
in QAPI types
* Don't parse QemuOpts, go straight to QAPI
* How do we distribute this work to multiple engineers?
* Examples:
* --blockdev API is used on the command-line
* --display
* qemu-storage-daemon command-line is largely QAPI-fied
* Alex Bennee:
* We should have a gold-standard reference with documentation
if we are to expect maintainers to convert their own flags
* -> John Snow will work on this document
* Do we have good examples of turning QemuOpts to QAPI?
* 53 of our 93 CLI flags that take arguments are QemuOpts, so
this is a major component
* Kevin: -monitor for the Qemu Storage Daemon, recently
* John Snow: Final milestone might be an automated QAPI-based CLI
parser, but only once QAPI types have been defined
* Does command-line order matter?
* Two options: allow any order OR left-to-right ordering
* Andrea Bolognani: Most users expect left-to-right ordering,
why allow any order?
* Eduardo Habkost: Can we enforce left-to-right ordering or do
we need to follow the deprecation process?
* Daniel Berrange: Solve compability by introducing new
binaries without the burden of backwards compability
* Unclear whether we will reach consensus on this call
about this. Maybe raise it on qemu-devel. [stefanha]
* Philippe: Easy command-line options (-drive) and
managent-friendly options (-blockdev) could be offered by different
binaries
* Daniel Berrange: Focussing on one new binary is more
achievable
* Board defaults, configuration file options
* How to set properties on existing objects (e.g. board defaults)?
* Andrea Bolognani: Perhaps represent the board defaults as a
list of ordered options, append user-provided options, and *only then*
create the object?
* Currently the boards create QOM objects directly, they
don't involve QAPI
* Stefan: How do QOM objects/properties fit into QAPI
CLI/configuration parsing?
* QAPI objects are processed by functions that will create
QOM objects
* Markus: -global is broken
* Eduardo: Long-term goal to describe QOM properties in QAPI
* Daniel Berrange: eliminate QOM boilerplate by describing
object properties in QAPI
* Markus: It's hard to use QAPI because QOM properties are
dynamic and can change at runtime
* Next steps
* John Snow and Markus will work on reference documentation
Bluejeans Chat Log
[ 9:02] Stefan Hajnoczi: https://etherpad.opendev.org/p/QEMUCLI
[ 9:05] John Ferlan: @stefan - there are some people in a different room....
[ 9:08] Daniel Berrange: if you're not talking please mute
[ 9:24] Alex Bennée: I ran into this ordering stuff w.r.t
semihosting and chardevs so knowing how to properly order things in
the "new world" would be useful
[ 9:33] Phil: YAML &anchor symbol is helpful to use a definition
from a previous layer
[ 9:34] Mdasoh: It makes sense to have ordered options when you're
talking about putting objects within objects; at the same time it
doesn't make so much sense to order them when you're talking about
running them all through a BNF parser (flex+yacc?) for user-friendly
configuration. So of course there would be two layers, and you would
translate the unordered options into a set of encapsulating or ordered
options.
[ 9:49] Andrea Bolognani: It Will Be Totally Different This Time™
[ 9:50] John Snow: ^ that's partly why I wanted to discuss this,
to set concrete goals and to be able to measure progress
[ 9:51] Alex Bennée: I'm afraid I have to drop off for the school
run - look forward to reading the reference docs ;-)
[ 9:51] John Snow: ^ ty Alex
[10:00] Stefan Hajnoczi: I need to drop now. I'll send the meeting
notes to the mailing list. Bye!
[10:00] Kevin: Same for me
[10:00] John Snow: OK!
next prev parent reply other threads:[~2020-10-06 18:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 9:09 KVM call for agenda for 2020-10-06 Juan Quintela
2020-10-02 15:16 ` John Snow
2020-10-05 14:46 ` Stefan Hajnoczi
2020-10-06 18:21 ` Stefan Hajnoczi [this message]
2020-10-07 17:50 ` Paolo Bonzini
2020-10-07 18:04 ` Daniel P. Berrangé
2020-10-08 11:25 ` Markus Armbruster
2020-10-08 14:15 ` Paolo Bonzini
2020-10-08 8:03 ` Kevin Wolf
2020-10-09 16:45 ` Eduardo Habkost
2020-10-10 4:41 ` Markus Armbruster
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=CAJSP0QVZcEQueXG1gjwuLszdUtXWi1tgB5muLL6QHJjNTOmyfQ@mail.gmail.com \
--to=stefanha@gmail.com \
--cc=jsnow@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@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).