qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: KVM call for agenda for 2020-10-06


From: Stefan Hajnoczi
Subject: Re: KVM call for agenda for 2020-10-06
Date: Tue, 6 Oct 2020 19:21:29 +0100

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!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]