All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: John Snow <jsnow@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Juan Quintela" <quintela@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Andrea Bolognani" <abologna@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: QEMU API cleanup initiative - Let's chat during the KVM call
Date: Tue, 6 Oct 2020 11:30:20 +0200	[thread overview]
Message-ID: <9b6c8327-7e53-ef1d-e576-1e091ca1e04f@redhat.com> (raw)
In-Reply-To: <8e8a7b4d-e3a8-efe0-47b0-d20186970cee@redhat.com>

On 05/10/20 16:52, John Snow wrote:
> - Markus considers the platonic ideal of a CLI one in which each flag is
> a configuration directive, and each directive that references another
> directive must appear after the directive in which it references.
> 
> - I tend to consider the ideal configuration to be a static object that
> has no inherent order from one key to the next, e.g. a JSON object or
> static flat file that can be used to configure the sysemu.
> 
> They're not compatible visions; and they have implications for error
> ordering and messages and so on.

I think they aren't incompatible.  Even your idea would probably forbid
cycles, so it only takes a topological sort to go from an unordered
configuration to an ordered one.  The only difference is whether it's
the user or the program that does it.

> For the meantime, Markus's vision is closer to what QEMU already does,
> so it's likely the winning answer for now and if a conversion to the
> other idea is required at a time later, we'll have to tackle it then. (I
> think.)
> 
> It's a good subject of discussion. (Also relevant: if parsing is to
> occur in more than the CLI context, the existing contextual CLI parser
> error system needs to be reworked to avoid monitor-unsafe error calls.
> It's not trivial, I think.)

I think parsing should occur in CLI context only, but errors can occur
elsewhere too.

I think the idea for this kind of refactoring is always to first make
the code behave the way you want, and only then change the
implementation to look the way you want.

Currently we have:

    switch (...) {
        case QEMU_OPT_...:
            /* something has side effects, something is just parsing */
    }

    init1();
    qemu_opts_foreach(something_opts, configure_something);
    init2();
    qemu_opts_foreach(some_more_opts, configure_some_more);
    init3();

    enter_preconfig();

We should first of all change it to

    parse_command_line() {
        apply_simple_options()l
        qemu_opts_foreach(something_opts, configure_something);
        qemu_opts_foreach(some_more_opts, configure_some_more);
    }

    switch (...) {
        case QEMU_OPT_...:
        /* no side effects on the initN() calls below */
    }

    init1();
    init2();
    init3();

    parse_command_line()

    enter_preconfig();

    more_init_that_needs_side_effects();

This way, the parse_command_line() and its qemu_opts_foreach callbacks
can become changed into a series of qmp_*() commands.  The commands can
be called within the appropriate loc_push() though.

Problem is, it's 1000 lines of initialization interspersed with
qemu_opts_foreach calls.  But it's doable.

Paolo



  reply	other threads:[~2020-10-06  9:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-04  0:14 QEMU API cleanup initiative - Let's chat during the KVM call John Snow
2020-10-05 13:45 ` Stefan Hajnoczi
2020-10-05 14:52   ` John Snow
2020-10-06  9:30     ` Paolo Bonzini [this message]
2020-10-06  9:40       ` Daniel P. Berrangé
2020-10-06  9:53         ` Paolo Bonzini
2020-10-06  9:50     ` Daniel P. Berrangé
2020-10-05 15:33 ` John Snow

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=9b6c8327-7e53-ef1d-e576-1e091ca1e04f@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=abologna@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.